Fork me on GitHub
#shadow-cljs
<
2021-04-27
>
zhuxun203:04:58

Where is the best place to set NODE_ENV? Do I just put a line of (set! js/NODE_ENV (if goog.DEBUG "development" "production") in my entry point? Is there a way to say this in the shadow-cljs.edn?

thheller06:04:59

its an env variable so you NEVER set it in your code

andre05:04:41

hi, can we make this work somehow with shadow https://www.npmjs.com/package/babel-plugin-assign-directive ?

Aron05:04:42

seems like there is a NOTE saying no 🙂

andre05:04:19

yes , thats why im here 🙂

Aron05:04:55

why the link is 404 from the package site?

Aron05:04:07

can't even read the source

andre05:04:56

idk its outdated, its possible to add directive with a macro , im more interesting in how we can use babel plugin for generated js code with shadow

andre05:04:53

or probably it could be not a bubel plugin, i mean we need access to js code to be able to change it in runtime

Aron05:04:40

I am not sure I fully understand. If I generate my js code with shadow-cljs, why would I take the output of that and try using another approach to modify it? Why not just modify at the beginning

Aron05:04:19

I know lots of tooling on how to modify js code from js, but that is in js land entirely

andre05:04:17

we need to get this user.i_use_worklet*=*function(){var _f*=*function _f(){*return* console.log("Hey I'm running on the UI thread");};_f._closure*=*{console*:*console};_f.asString*=*"function(){const{console}=this._closure;{return console.log(\"Hey I'm running on the UI thread\");}}";global.__reanimatedWorkletInit(_f);*return* _f;}(); from this user.i_use_worklet*=*function(){"worklet";*return* console.log("Hey I'm running on the UI thread");};

andre06:04:43

hm actually, probably we need this only in the release build

thheller06:04:13

@andre I don't know how this works at all but maybe you want to write the worklet code directly in JS and just use it from CLJS? or do you really need to write those in CLJS?

andre06:04:48

so my idea is to run re-frame event handlers in a separate thread, so yeah it should be cljs code

andre07:04:38

but for my idea i don't need it in develop, only in production for performance reasons

thheller07:04:57

the main issue is that :advanced will likely remove the "worklet;" thing

andre07:04:12

yeah, i also thought about this

thheller07:04:18

it'll also agressively inline functions and so on so the code is never what you wrote after :advanced

andre07:04:45

yeah thats true

thheller07:04:57

also I don't have a clue how worklets actually work but I'd assume it would require a lot of serialization

thheller07:04:11

if it all runs in a separate thread and you can't share memory in JS

thheller07:04:37

so running re-frame event handlers seems like an absolute no go for me? too much overhead serializing the app-db back and forth?

thheller07:04:12

> When you pass arguments, they will be copied to the UI JS context.

andre07:04:21

seems like that 😞

thheller07:04:23

https://www.npmjs.com/package/babel-plugin-assign-directive the github repo for this doesn't exist anymore so I think this never actually worked? can't see how this would work with any other CLJS tool either as :advanced or even :simple would be the major hurdle here

thheller07:04:55

so the only way I see this working is with actual JS functions just called from CLJS but not passing through CLJS tooling, just metro

andre07:04:49

yeah, thanks

thheller07:04:59

a custom worklet-fn special form could be created to create the code you need but yeah its applications are very limited and I don't expect this to ever work for functions using CLJS datastructures anywhere. basic JS types maybe work though.

borkdude10:04:03

how should those warnings be fixed for shadow?

borkdude10:04:40

Note that the code does work, also under advanced

thheller11:04:50

@borkdude first of all this has nothing to do with shadow-cljs, you'd get those warning for regular CLJS as well if you were to enable them. so the only difference is that shadow-cljs defaults to having them enabled automatically vs. manually. You can either use (set! *warn-on-infer* false) somewhere above those forms if you know they are safe and can be renamed (which they likely can)

borkdude11:04:20

@thheller Adding an extra local type hint solved the warnings. I don't understand why because that type hint was already on the return tag of the function. But thanks. It was reported by a shadow-cljs users, I have never seen this warning before.

thheller11:04:22

unsure why the return type hint is missing though. that should be ok

borkdude11:04:02

I will check out warn-on-infer, it sounds useful

thheller11:04:28

yeah if you set that to true you should get the warnings with the regular cljs compiler too

thheller11:04:52

basically shadow-cljs just sets that to true by default for local files (ie. files not in .jar)

thheller11:04:52

I do remember some weird issue with return type hints but not sure. I think in some places it was a little inconsistent and (defn ^Return foo [] ...) worked but (defn foo ^Return [] ...) didn't

thheller11:04:31

or the other way. you really don't see them used all that often :P

iGEL14:04:09

Hello. I have another question, probably quite stupid again, but I'm banging my head against this for a few hours. I'm trying to adapt this example: https://github.com/reactchartjs/react-chartjs-2/blob/master/example/src/charts/Line.js

(ns my-app.views
  (:require ["react-chartjs-2" :refer [Line]]))

(defn chart []
  [:> Line
      {:data {:labels ["1" "2" "3" "4" "5" "6"]
              :datasets [{:label "# of Votes"
                          :data [12 19 3 5 2 3]
                          :fill false
                          :backgroundColor "rgb(255, 99, 132)"
                          :borderColor "rgba(255, 99, 132, 0.2)"}]}
       :options {:scales {:yAxes [{:ticks {:beginAtZero true}}]}}}])
But I get this error:
error when calling lifecycle function my-app.core/mount-root Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports. Check the render method of `my-app.views.chart`.
Line seems to be undefined and I don't know why. Both "chart.js": "^3.1.1" and "react-chartjs-2": "^3.0.2" are in my package.json. I'm quite sure it was working yesterday, but don't know what I've changed

Aron14:04:59

So what is Line?

Aron15:04:43

oh, i can't read, sorry, you said it's undefined

iGEL15:04:43

It should be a react component, provided by react-chartjs-2

Aron15:04:14

can you check how that component exports? sometimes people do weird things

Aron15:04:39

although if it was working and you didn't update anything then it's probably not that

iGEL15:04:09

I've added nouislider-react to the project, but I just removed it and it's still not working. What should I look for in the exports? I'm not too familiar with JS modules and exports, but I found this in node_modules/react-chartjs-2/dist/index.js:

var Line = React.forwardRef(function (props, ref) {
  return React__default.createElement(ChartComponent, Object.assign({}, props, {
    type: 'line',
    ref: ref,
    options: props.options || {}
  }));
});

Aron15:04:15

there should be either export or module exports

Aron15:04:35

but I don't think that's the issue if it was working, more likely a typo or similar issue

iGEL15:04:14

I guess it was a caching issue. I deleted everything and restored it from git and restarted shadow-cljs. Now it's working. Thank you anyway!

iGEL15:04:31

I thought I tried that before, but this time I removed not just the node modules, but everything

Aron15:04:02

glad it's working 🙂