This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-15
Channels
- # beginners (56)
- # boot (4)
- # cider (22)
- # clara (10)
- # cljs-dev (50)
- # cljsrn (27)
- # clojure (27)
- # clojure-conj (4)
- # clojure-dev (3)
- # clojure-italy (17)
- # clojure-nl (12)
- # clojure-norway (3)
- # clojure-spec (10)
- # clojure-uk (137)
- # clojurescript (132)
- # cursive (4)
- # datascript (2)
- # datomic (109)
- # devcards (2)
- # editors (1)
- # emacs (4)
- # euroclojure (2)
- # events (4)
- # figwheel (1)
- # fulcro (15)
- # jobs (1)
- # jobs-discuss (4)
- # juxt (3)
- # leiningen (2)
- # off-topic (21)
- # onyx (13)
- # other-languages (8)
- # pedestal (6)
- # re-frame (22)
- # reagent (5)
- # reitit (1)
- # ring-swagger (3)
- # shadow-cljs (75)
- # sql (6)
- # tools-deps (2)
- # vim (1)
- # yada (8)
wait why do you have to build your own react if you want to use a react component? i never have
@lee.justin.m could it be that some component requires a specific react version?
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)
Is there a place in om-next where I can put an initial component local state?
@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
@roti there are om.next/set-state! and om.next/update-state! methods which reference “local state” in the documentation.
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
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
@andreasklein can you give a link?
To the documentation? https://github.com/omcljs/om/wiki/Documentation-(om.next)#set-state
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).
@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
@roti I have a component with a query already. I only want to track some local state so I have a mixture of both.
ClojureScript 1.10.312 released https://clojurescript.org/news/news
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
@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
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)
This looks excellent! https://clojurescript.org/guides/webpack As a node n00b, is this also useful for “server side” cljs?
@wilkerlucio need more information
@wilkerlucio make something minimal, we test that stuff and nothing came up
ok, I'll try to make a minimum repro
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?
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
however this isn’t true, we worked on externs inference and global exports to allow an alternative approach - foreign-lib
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
I don’t really care about making this any easier as that kind of stuff is best handled by the community
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.
@dnolen got a min, just starting from the demo on cljs.main, using this as source code:
(ns my-app.core
(:require [cljs.spec.alpha :as s]
[clojure.test.check.generators :as gen]))
(js/console.log (s/gen nil?))
doesn't compile
@wilkerlucio thanks
wait, sorry, I forgot to add test.check on this repro
let me try adding this first
is there a recommended version for test.check on this case? I'm using 0.9.0 on the project
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
@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
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?
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
this sounds like going back and forth, why didn't cljs embraced the npm ecosystem from the start?
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
My guess would be technical reasons, after all the cljs compiler is a JVM program. Can be wrong though.
@lockdown- well, I share them as a jar via a “maven repo”, like installed/deployed from lein/boot/whatever
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.
@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
I’ll reiterate, this fairly minimal webpack gunk can be automated by some a la carte libraries if somebody cares enough
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.
Say I’m in a company, want to make a module that has common Reagent components to use across various web apps
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.
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.
so if you want to make some internal lib that bundles a bunch of stuff that requires webpack step - go for it
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.
you don’t have to bundle js bundle together with cljs bundle btw, we are fine with two bundles for years
I think he's talking more about how to inform its users/consumers about the deps of his cljs lib
one js bundle is reused across many cljs web apps that we have using a simple script tag
@roman01la yeah, I don’t mean to have a single bundle, one for JS, one for cljs
@mikerod also nothing is stopping you from making a shared company JAR with a bundle.js file in it
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
most pain points, and many apps that I’ve seen are well served by this small enhancement
I agree, having this bundling stuff working better and documented is a great step. I’m excited about it.
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
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.
@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
@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
@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
File a minor issue - doesn’t matter really as long as multiple advanced runs work - people usually clean before too
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...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@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
be careful... once you try it there is no turning back 😛
I have to say it is very nice on node
only projects
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...
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)
yeah, the inability to use CSS loaders in CLJS is what drove me to explore CSS-in-(CL)JS
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
😅 well the nice thing about it too, is that CLJS can interface with most any of the CSS-in-JS libs
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