This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-06
Channels
- # aleph (15)
- # beginners (40)
- # boot (14)
- # cider (90)
- # cljs-dev (132)
- # cljsrn (25)
- # clojars (7)
- # clojure (188)
- # clojure-chicago (4)
- # clojure-dusseldorf (1)
- # clojure-greece (9)
- # clojure-italy (43)
- # clojure-russia (16)
- # clojure-sg (7)
- # clojure-spec (39)
- # clojure-uk (81)
- # clojurescript (170)
- # component (5)
- # core-async (7)
- # cursive (49)
- # data-science (65)
- # datascript (3)
- # datomic (27)
- # graphql (3)
- # hoplon (4)
- # instaparse (56)
- # klipse (129)
- # leiningen (1)
- # lumo (28)
- # off-topic (4)
- # om (15)
- # onyx (54)
- # overtone (7)
- # pedestal (7)
- # re-frame (9)
- # reagent (72)
- # ring (33)
- # ring-swagger (2)
- # spacemacs (1)
- # untangled (19)
- # vim (2)
- # yada (12)
@dnolen, I think this PR is related: https://github.com/cljsjs/packages/pull/1192
String based require could also solve decoupling libraries from one library source if those requires also with with UMD modules
for example if (:require ["react" :as react :refer (createElement)])
would point createElement
to js/React.createElement
when using cljsjs/react
Then all the libraries could use this require form and it would point to whatever React is provided in users project
Though I guess mapping those refer etc. symbols to objects in window
would be challenging
for node they are very nice as they just work, if you run code through webpack they just work
shadow-cljs
will put all string requires it finds into a manifest.json
in the :output-dir
just register the name it provides somehow (cljs.foreign/register "react" js/React)
or so
It works for files that provide single object, but there are JS libs that don't do that
But if supporting those libs that only export single object is enough, foreign-libs could be extended to support this {:provides ["react"] :provides-object "React"}}
or such, where :provides-object
is the object that requires referring to the provided ns would point to
@juhoteperi my thought was the there would be actual .cljs
files that would “configure” what the provided JS files do
so there would be a cljsjs/react.cljs
that would (cljs.foreign/register "react" js/React)
I don't see what is the benefit in this compared to foreign-libs
this is the endgame for me https://dev.clojure.org/jira/browse/CLJS-2061
I think that is going to be unnecessary once the first is implemented properly
yes, I just want to stop this https://github.com/cljsjs/packages/pull/1192 from becoming a thing
There is clearly interest now to fix this so I'll keep that blocked for some weeks to see what solutions we can come up with
it sucks that I can’t take my implementation for https://dev.clojure.org/jira/browse/CLJS-2061 into core but hopefully someone else can implement it somehow
would also be neat if :foreign-libs
could still be used as a fallback for the browser and :externs
. it just works for node but requires work for the browser.
@thheller yeah just not interested in mapping to require
and don’t care about Webpack integration at all
@pesterhazy hrm I don’t know about surrogate package like that
the only thing we’re interested in at all is Google Closure stuff and Google Closure support for Node modules
not sure I understand what you mean by that but I don’t have to if you agree with string requires
@juhoteperi I’m concerned that wouldn’t be enough anyway given many package freely use exports and don’t export one logical thing
@pesterhazy that style of package shim is not what I’m getting at since old style :foreign-libs
just create globals - you can’t really fix that now. Google Closure JS modules don’t.
@dnolen, I don't love surrograte packages either, but I'm trying to figure out what's the most pragmatic way to include unpatched reagent/om/... without pulling in cljsjs/react
so the shim really needs to create a ClojureScript namespace which manually exports the right thing depending on which dep you have
so you would prefer a react surrogate package that includes empty namespaces instead of relying on foreign-libs?
people aren’t using random things from NPM so the old style :foreign-libs
don’t really apply to them
@pesterhazy the namespace cannot be empty
one for the old way with CLJSJS and one for the new way - and people can control what they get with Maven coordinates
the point here is that end users now can just use NPM React without thinking about it or changing much
I'm just testing npm-deps and while React is parsed okay by Closure, create-react-class is not 😄
@dnolen, would we have to change Reagent/Om as well?
@pesterhazy that’s right but it would be a boring change - the best kind
Would these CLJS namespaces be written by hand or generated automatically?
just (:require ["react" :as react])
and have some way for :foreign-libs
or :npm-deps
to provide that somewhere .. no need for cljsjs.alias
mess
From working with react-native, I know that Reagent needs to be able to access React from window.React
as well, because there we kind of have to co-operate with the react-native packager
so for that we'd have a shim library that grabs React from window.React, and exports it?
That would be pretty much what cljsjs/React does, that also uses window.React
@pesterhazy I’m sure there will be stuff like that - but doesn’t sounds like something for what I’m talking about to be concerned about
but there could be a third shim for react-native which doesn't include the browser JS file like Cljsjs/React, but also uses window.React
@juhoteperi it remains to be seen - first just want to see if it works - and then perhaps it can be sugared / automated
Right, sounds good
but I really don’t think so, this is about some JS package in a graph that everyone else is depending on
a change with little impact that makes it easy to use foreign js would be great
could you explain what you meant by your comment on webpack above?
I think the approach outlined here: http://blob.tomerweller.com/reagent-import-react-components-from-npm is pretty powerful
ah ok not supporting js/require
makes a ton of sense
the advantage of using webpack as a compnaion - to build a second bundle - is that you tap into a world of packages that get a lot of eyeballs
I mean, everyone in js land tests with webpack
ES6 doesn’t change anything as long as there are things like JSX and babel .. the JS world is just getting started with this mess
we piggieback heavily on the React ecosystem and that’s an ecosystem jumping on the ES6 bandwagon
node with .mjs
should help as well .. but all this is going to take time … I personally don’t want to wait for that
really only needs string requires to solve almost every issue if we also can get rid of the pseudo namespaces in cljsjs packages
When a module (`create-react-class`) exports only a single function as the the object, is there a way to refer to that with current npm-deps?
@juhoteperi should be, since https://dev.clojure.org/jira/browse/CLJS-1968
Okay. Now looks like browser just can't load React because it tries to read process.ENV.NODE_ENV
which is not available
@juhoteperi Try adding this to your project
(ns process.env)
(goog-define NODE_ENV "development")
I added this to index.html for now: var process = {env: {NODE_ENV: "development"}};
@juhoteperi yes that pattern is supported now
Yes, got that working, now trying to use react-dom/server
Any workarounds? JS file which provides react-dom-server
and exports require("react-dom/server")
?
I thought the problem would be to just require it but I guess the file is not even indexed by node-inputs
: https://github.com/clojure/clojurescript/blob/ccebc81419a9611e9521c2741c69851eebf327c0/src/main/clojure/cljs/closure.clj#L2115
@juhoteperi not indexed because we only index things explicitly required by the build
That is not based on requires but npm-deps
NPM feature crawls dep graph for just those modules required by package index files
e.g. react-dom/index.js
but it skips react-dom/server.js
Even if there was support for (:require ["react-dom/server"])
a change would also be needed to index react-dom/server.js
because current code doesn't include that file in foreign-libs
@juhoteperi Instead of using :npm-deps
, you can build up :foreign-libs
yourself by calling node-inputs
add whatever is missing for you. This is what I do to get the react-dom.server
ns.
Except for single function export of create-react-class
it would be possible to create shim react
and react-dom
cljs namespaces which refer to window.React
and window.ReactDOM
And I guess it would be as easy to create shim which refers to require("react")
for Node
@juhoteperi There is a npm-deps branch? Good to know. Thanks! 🙂
Just created it. Not going to be merged as is, just for testing
Got the advanced build also working. Reagent demo site down from 462KB to 434KB (non-gzipped).