Fork me on GitHub
#clojurescript
<
2018-06-15
>
justinlee00:06:24

wait why do you have to build your own react if you want to use a react component? i never have

johnj00:06:14

@lee.justin.m could it be that some component requires a specific react version?

justinlee00:06:47

i mean, it could but it certainly isn’t “nearly always” the case

justinlee00:06:55

oh I bet by “build” he means webpack build, i.e., include a specific version of react in the bundle (though even then, most react components i’ve used are not super specific to versions of react, though that may start to change with the lifecycle changes)

dnolen00:06:50

Yes webpack build

andreasklein09:06:01

Is there a place in om-next where I can put an initial component local state?

roti09:06:25

@andreasklein no, in om-next the entire app state is in one place, and each component must specify via a query what data it needs

roti09:06:12

if you can make components have local state, it is surely not in the spirit of om-next

andreasklein09:06:21

@roti there are om.next/set-state! and om.next/update-state! methods which reference “local state” in the documentation.

roti09:06:55

if I remember well, state changes are also queries (sort of like transactions) which define what needs to be changed, this can be the same data from the query, but also something else

roti09:06:43

you could call the data from the component query local, but the fact is that it can be requested by other components as well, which doesn't quite fit with the concept of local

roti09:06:03

@andreasklein can you give a link?

roti09:06:37

hmm, I would guess that's a mistake in the documentation (or a remnant from the original om). I may be wrong, but my understanding is that local state is specifically avoided in om-next (with local state meaning, it's hidden inside the component, and can't be accessed or changed from outside).

andreasklein09:06:26

@roti As far as I see it. component local state works in om.next as expected. I put the initialization of the state in componentWillMount which seems to work

roti09:06:48

without having defined a query?

andreasklein09:06:44

@roti I have a component with a query already. I only want to track some local state so I have a mixture of both.

roti09:06:50

and the local state does not have to do anything the query?

roti09:06:05

then I'm wrong, and local state is possible 🙂

dnolen14:06:25

lots of little stuff but the big news is better support for easy integration with Webpack, feedback welcome on the new official guide https://clojurescript.org/guides/webpack

wilkerlucio14:06:12

@dnolen I just tried upgrading, but then I got problems with spec, it started complaining that clojure.test.check.generators isn't loaded, but I double check and it is, reverting to 1.10.238 gets it back working again

wilkerlucio14:06:33

alpha.cljs:70 Uncaught Error: Var clojure.test.check.generators/return does not exist, clojure.test.check.generators never required
    at alpha.cljs:70
    at cljs.spec.gen.alpha.LazyVar.cljs$core$IDeref$_deref$arity$1 (alpha.cljs:22)
    at Object.cljs$core$_deref [as _deref] (core.cljs:673)
    at Object.cljs$core$deref [as deref] (core.cljs:1449)
    at Function.cljs$core$IFn$_invoke$arity$variadic (alpha.cljs:70)
    at alpha.cljs:91
    at cljs.core.Delay.cljs$core$IDeref$_deref$arity$1 (core.cljs:10369)
    at Object.cljs$core$_deref [as _deref] (core.cljs:673)
    at Object.cljs$core$deref [as deref] (core.cljs:1449)
    at Object.cljs$spec$gen$alpha$gen_for_pred [as gen_for_pred] (alpha.cljs:148)

borkdude14:06:09

This looks excellent! https://clojurescript.org/guides/webpack As a node n00b, is this also useful for “server side” cljs?

dnolen14:06:18

@wilkerlucio need more information

dnolen14:06:30

@borkdude not really since server side already works more or less

dnolen14:06:30

@wilkerlucio make something minimal, we test that stuff and nothing came up

wilkerlucio14:06:59

ok, I'll try to make a minimum repro

borkdude14:06:45

so the idea of this webpack usage is: make one bundled foreign library from multiple npm deps. webpack will take care of some module format that cljs understands, so it can infer externs?

dnolen14:06:39

the problem is this - :npm-deps is still too bleeding edge - when it works it’s amazing but there too many cases that either we don’t handle or Closure doesn’t handle. So people believe there’s some innate reason we can’t integrate with node_modules

dnolen14:06:34

however this isn’t true, we worked on externs inference and global exports to allow an alternative approach - foreign-lib

dnolen14:06:16

there was some minor things to fix in both features and now you can just use webpack and let it deal with all the node_modules craziness

dnolen14:06:43

really this is how shadow-cljs works too, it just makes it easier

dnolen14:06:08

I don’t really care about making this any easier as that kind of stuff is best handled by the community

dnolen14:06:36

i.e. write clj-new template and some a la carte webpack driver Clojure library

borkdude14:06:13

it seems pretty easy this way. it sounds like I was saying the same thing after reading your explanation, so not sure what I’ve misunderstood. let webpack deal with the npm side. let cljs import the result as a foreign library. don’t know the details, but if this works, it’s great.

wilkerlucio14:06:50

@dnolen got a min, just starting from the demo on cljs.main, using this as source code:

wilkerlucio14:06:51

(ns my-app.core
  (:require [cljs.spec.alpha :as s]
            [clojure.test.check.generators :as gen]))

(js/console.log (s/gen nil?))

wilkerlucio14:06:57

doesn't compile

dnolen14:06:01

@borkdude sorry I probably misread what you said about

borkdude14:06:27

np, congrats on the new release!

dnolen14:06:05

will probably cut a release to fix that once I sort it out

wilkerlucio14:06:15

wait, sorry, I forgot to add test.check on this repro

wilkerlucio14:06:21

let me try adding this first

dnolen14:06:52

k I was feeling skeptical but dynaload uses exists? which changed

wilkerlucio14:06:55

is there a recommended version for test.check on this case? I'm using 0.9.0 on the project

dnolen14:06:07

I would test with latest

wilkerlucio14:06:00

ok, just FYI, it worked adding test.check, so I'll try to dig it, I'm using shadow on the real project, can be something around there

dnolen14:06:09

@wilkerlucio k, like I said we run test check on our own tests so I’m skeptical this is an issue with ClojureScript alone anyway

mikerod15:06:15

Here’s a question on this webpack-bundling idea (which I like and use): When I write a cljs library that I intend to have other cljs app’s consume, I run into a problem of “transitive dependencies” I believe. If my shared lib A has a webpack config to build an appropriate bundle to use as :foreign-libs, the consumers have to also be aware of these dependencies and add them to their webpack config. So the consumers basically have to be fully aware of all the dependencies needed by this shared lib A and they have to (manually) replicate the dependency configuration into their own webpack bundle. Is that the state of things, or is there something else I have missed?

mikerod15:06:11

Perhaps the shared lib should publish it’s node module deps part via npm or something so it can be brought in via the typical dependency resolution of the consumer’s webpack/yarn etc

johnj15:06:12

how do you distribute/share your shared lib?

johnj15:06:45

this sounds like going back and forth, why didn't cljs embraced the npm ecosystem from the start?

justinlee15:06:43

note that neither webpack nor browserify had been released when clojurescript was started. this business of using node modules on the browser is old hat today but in reality it’s a pretty recent development

richiardiandrea15:06:47

My guess would be technical reasons, after all the cljs compiler is a JVM program. Can be wrong though.

mikerod15:06:59

@lockdown- well, I share them as a jar via a “maven repo”, like installed/deployed from lein/boot/whatever

mikerod15:06:37

so yeah, I guess could deploy the whole shared project as a npm module instead of a jar at all… maybe. Don’t know about that.

dnolen15:06:28

@mikerod that’s not how it works

dnolen15:06:37

it doesn’t matter what’s in your transitive graph

dnolen15:06:55

all you need to do export the libs you intend to use - done

mikerod15:06:28

I’m definitely missing something here then.

johnj15:06:46

@mikerod yeah, that's I think how it should work, your compiled cljs with a package.json in npm, but I'm new to this so not sure

dnolen15:06:50

I’ll reiterate, this fairly minimal webpack gunk can be automated by some a la carte libraries if somebody cares enough

☝️ 4
bhauman20:06:22

and I've got a library in mind

dnolen15:06:57

@mikerod oh you’re talking about something else, sorry

dnolen15:06:06

yeah just don’t do that

mikerod15:06:14

My understanding: If my shared lib makes a bundle and uses it for :foreign-libs, say it uses react-select, react-datepicker. My consumer has to also create a bundle to include react-select & react-datepicker and wire it up to their :foreign-libs as a bundle or whatever they want to do.

dnolen15:06:34

and there’s really no point IMO

dnolen15:06:42

wrapping stuff is almost never a good idea

mikerod15:06:43

Don’t make shared cljs libs? 😛

dnolen15:06:55

don’t do it - no problems

mikerod15:06:18

Say I’m in a company, want to make a module that has common Reagent components to use across various web apps

mikerod15:06:27

These Reagent components may use npm deps

mikerod15:06:49

I thought it’d be fairly common to want to share things like that

mikerod15:06:26

I’m fine with just having to replicate the bundle stuff anyways and can maybe even figure ways to make it easier. I’m just making sure there were no secrets to doing it already built in.

dnolen15:06:16

let’s rewind a bit

dnolen15:06:21

A) don’t (trivially) wrap libraries

mikerod15:06:21

I don’t think of wanting to share some component lib that may use a few lower-level npm libs to be just a “wrapper”. It can be more sophisticated stuff than that.

dnolen15:06:31

B) deps.cljs upstream works

dnolen15:06:04

so if you want to make some internal lib that bundles a bunch of stuff that requires webpack step - go for it

mikerod15:06:13

So, if my upstream jar includes it’s bundle.js in it, and has it’s :foreign-libs setup, my downstream project will not have to worry about including that bundle.js stuff? Of course, it still may have to worry if it is going to be including the same dependencies (duplicate deps) in a bundle of its own.

Roman Liutikov15:06:13

you don’t have to bundle js bundle together with cljs bundle btw, we are fine with two bundles for years

johnj15:06:25

I think he's talking more about how to inform its users/consumers about the deps of his cljs lib

Roman Liutikov15:06:42

one js bundle is reused across many cljs web apps that we have using a simple script tag

👍 4
mikerod15:06:45

@roman01la yeah, I don’t mean to have a single bundle, one for JS, one for cljs

dnolen15:06:58

@mikerod also nothing is stopping you from making a shared company JAR with a bundle.js file in it

mikerod15:06:24

Ok, that’s fine. I think I understand the general mechanics then. Was just checking.

mikerod15:06:32

Thanks for the pointers.

dnolen15:06:52

you are right that there is no intention here to fundamentally treat Webpack as a supported build step the way we want :npm-deps to be a build step. but really this is a nice to have

dnolen15:06:12

most pain points, and many apps that I’ve seen are well served by this small enhancement

👍 4
mikerod15:06:13

Yeah, that makes sense to me.

mikerod15:06:35

I agree, having this bundling stuff working better and documented is a great step. I’m excited about it.

dnolen15:06:26

it removes the fog around how it can work

dnolen15:06:34

people can experiment with automation

dnolen15:06:31

also it’s not like integrating with webpack is off the table - we just move very slow and anything we might do needs to get hammocked

👍 20
thheller16:06:03

I'll probably write a blog post about why shadow-cljs doesn't use webpack because several prototypes for the npm stuff did. might be something useful to learn for others trying to do it.

👍 16
justinlee16:06:18

@thheller that would be very informative. i’ve often idly thought that some kind of tight integration between shadow and webpack would be the best of both worlds

tungsten16:06:18

@dnolen @bhauman I updated my "es6 module with foreign libs test project" from yesterday with the new version of CLJS. Unfortunately it seems like I am still hitting the same error as yesterday. Hopefully it is something simple. Readme is updated with the verbose log as well. Let me know if there is anything I can provide that would be of use. https://github.com/briangorman/es6test

dnolen16:06:46

@bfast you really want to make more minimal issues, cljs.main and no Figwheel please

johnj17:06:30

@dnolen per the webpack tutorial, if you run clj -m cljs.main -co build.edn -v -c a second time without touching anything the contents of inferred_externs.js get wiped out

dnolen17:06:44

File a minor issue - doesn’t matter really as long as multiple advanced runs work - people usually clean before too

johnj17:06:01

Ok, yeah for advanced it doesn't happen

nrako17:06:46

I could not tell from the previous discussion if :npm-deps should not be used? Nevertheless, I have been trying it out and hoping to get some help on an error. After compiling, I have this from the react-map-gl lib (https://github.com/uber/react-map-gl) -

(ns app.component
  (:require [react-map-gl :as M]))

(js/console.log M)
M logs correctly to the console. However, when drilling down into one of the properties, BaseControl for example, it throws Exception: ReferenceError: ...$node_modules$react_map_gl$dist$esm$components$base_control is not defined at Object.get BaseControl [as BaseControl] How might I debug? I don’t know if it is a library issue, cljs, or user error. Will post the relevant source code in a thread...

nrako17:06:15

Repo - https://github.com/nrakochy/react-map-gl-failing Here’s the relevant index from the project which seems to correctly export BaseControl

export{default as BaseControl}from"./components/base-control";
//# sourceMappingURL=index.js.map
and this ./components/base-control does seem to be where this export expects it, in ./components/base-control.js. Here is where the get BaseControl() error occurs-
goog.provide("...path$node_modules$react_map_gl$dist$esm$index");
goog.require("...path$node_modules$react_map_gl$dist$esm$components$interactive_map");
var experimental$...$node_modules$react_map_gl$dist$esm$index = {
    MapControls: ...path$node_modules$react_map_gl$dist$esm$utils$map_controls["default"]
};
var ...path$node_modules$react_map_gl$dist$esm$index = {
    get default() {
        return ...path$node_modules$react_map_gl$dist$esm$components$interactive_map["default"]
    },
    get InteractiveMap() {
        return ...path$node_modules$react_map_gl$dist$esm$components$interactive_map["default"]
    },
    get StaticMap() {
        return ...path$node_modules$react_map_gl$dist$esm$components$static_map["default"]
    },
    get BaseControl() {
        return ...path$node_modules$react_map_gl$dist$esm$components$base_control["default"]
    },
    get Marker() {
        return ...path$node_modules$react_map_gl$dist$esm$components$marker["default"]
    },
    get Popup() {
        return ...path$node_modules$react_map_gl$dist$esm$components$popup["default"]
    },
    get NavigationControl() {
        return ...path$node_modules$react_map_gl$dist$esm$components$navigation_control["default"]
    },
    get CanvasOverlay() {
        return ...path$node_modules$react_map_gl$dist$esm$overlays$canvas_overlay["default"]
    },
    get HTMLOverlay() {
        return ...path$node_modules$react_map_gl$dist$esm$overlays$html_overlay["default"]
    },
    get SVGOverlay() {
        return ...path$node_modules$react_map_gl$dist$esm$overlays$svg_overlay["default"]
    },
    get TRANSITION_EVENTS() {
        return ...path$node_modules$react_map_gl$dist$esm$utils$transition_manager.TRANSITION_EVENTS
    },
    get TransitionInterpolator() {
        return ...path$node_modules$react_map_gl$dist$esm$utils$transition$index.TransitionInterpolator
    },
    get LinearInterpolator() {
        return ...path$node_modules$react_map_gl$dist$esm$utils$transition$index.LinearInterpolator
    },
    get FlyToInterpolator() {
        return ...path$node_modules$react_map_gl$dist$esm$utils$transition$index.ViewportFlyToInterpolator
    }
};
...path$node_modules$react_map_gl$dist$esm$index.experimental = experimental$...$node_modules$react_map_gl$dist$esm$index
Would appreciate any insight

dnolen17:06:26

@nrako I think the official stance for the near future is that :npm-deps should be considered an advanced feature for users who want to help push that forward

dnolen17:06:57

if you just want to get stuff done read the Webpack guide or use shadow-cljs

nrako17:06:59

okay will try out those options. Thanks

benzap20:06:45

A lot of talk about shadow-cljs, think my next project I will have to consider it 🙂

wilkerlucio20:06:48

be careful... once you try it there is no turning back 😛

richiardiandrea20:06:42

I have to say it is very nice on node only projects

cjsauer21:06:25

If I'm pulling in a React library built with Webpack that contains a .css file for styles, what's the cljs method for loading that into my app? The docs for the project say to use import "../node_modules/path/to/css", but I'm pretty sure cljs's require facilities can't do that...

dnolen21:06:33

Webpack must put that css file somewhere just use it

dnolen21:06:49

importing CSS isn’t a thing in ClojureScript

cjsauer21:06:31

Gotcha. I just built a poor man's shadow hook that will do the trick for now...

(defn copy-files
  {:shadow.build/stage :flush}
  [build-state & {:keys [dest files]}]
  (println (format "Copying files to %s" dest))
  (doseq [f files]
    (println f)
    (let [file (io/file f)]
     (io/copy file (io/file dest (.getName file)))))
  build-state)

cjsauer21:06:42

Probably a lib floating around for this I imagine

cjsauer21:06:39

From here I can at least get it into my public folder and load them from index.html

lilactown21:06:01

yeah, the inability to use CSS loaders in CLJS is what drove me to explore CSS-in-(CL)JS

lilactown21:06:03

I like it so far

lilactown21:06:26

writing CSS in EDN next to the rest of my code is nice

cjsauer21:06:24

I can imagine. That might be something worth considering. Unfortunately my coworker is a JS/CSS dev, so that might be a tough sell haha

lilactown21:06:02

😅 well the nice thing about it too, is that CLJS can interface with most any of the CSS-in-JS libs

lilactown21:06:58

we have a consulting company building a bunch of widgets in vanilla ReactJS/webpack/etc., and we just told them they had to use emotion.sh and it interfaces with all our code out of the box

cjsauer21:06:00

We're in a similar position. I'm consuming a React/webpack library built by my coworker, but I left it up to him to choose what he enjoys using..

lilactown22:06:10

what React wrapper lib are you using?

lilactown22:06:16

just curious

cjsauer02:06:27

we're using reagent. you?

cjsauer21:06:21

Pretty sure I can make it work, but it's worth some reconsideration...