This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-29
Channels
- # architecture (2)
- # bangalore-clj (2)
- # beginners (177)
- # boot (1)
- # cider (36)
- # clara (15)
- # cljs-dev (30)
- # cljs-experience (6)
- # cljsrn (7)
- # clojure (94)
- # clojure-argentina (2)
- # clojure-brasil (1)
- # clojure-dusseldorf (6)
- # clojure-greece (1)
- # clojure-italy (18)
- # clojure-norway (4)
- # clojure-quebec (1)
- # clojure-russia (28)
- # clojure-sg (3)
- # clojure-spec (12)
- # clojure-turkiye (1)
- # clojure-uk (12)
- # clojurescript (169)
- # code-reviews (4)
- # community-development (2)
- # core-async (6)
- # core-matrix (6)
- # cursive (35)
- # datomic (18)
- # devcards (4)
- # euroclojure (1)
- # hoplon (2)
- # keechma (4)
- # klipse (2)
- # leiningen (1)
- # luminus (16)
- # mount (1)
- # off-topic (34)
- # om (31)
- # pedestal (6)
- # re-frame (14)
- # reagent (33)
- # specter (4)
- # uncomplicate (8)
- # unrepl (15)
- # untangled (24)
- # yada (25)
curious to hear some thoughts on the subject, happy to discuss my chosen implementation
Foreign-libs can be used without re-packaged NPM packages.
And foreign-libs can already be used to provide react
and without module-processing it should directly use the exported React object instead of global React
object
If I remember correctly, one thing foreign-libs are missing is support for example require('react-dom/server')
@thheller I love it
@juhoteperi yeah :foreign-libs
can probably be modified a bit a make this work. most CLJSJS packages are however not set up that way.
I'd compare this against :npm-deps
+ foreign-libs more than against Cljsjs
But yeah, I guess using strings for names will be the easiest way to use the same names as in JS
didn’t want to compare it to anything, in some sense it is just syntax sugar to what you can currently do
just noticed that I currently have to work around CLJSJS a bit but that is quite common nowadays I guess
Yeah, I think we need to either some way for libraries to be agnostic to how the deps are provided, or have a common naming convention Cljsjs and all the other ways can use
it works nicely for node.js
code but the extra build step for browser targets isn’t as nice as :foreign-libs
+ CLJSJS
works nicely if you are using a JS build tool anyways though (ie. webpack, create-react-app, create-react-native-app, etc)
I'm just trying to use :npm-deps
with Reagent and I think the current Reagent code won't work unless I create a shim NS for cljsjs.react
which defines js/React
and exports the functions requires by Reagent to that object 😕
Huh, and is React from :npm-deps
even supposed to work with just Closure module-processing, it is trying to call process
& other strange things
Though it is possible that that is caused by my Boot tooling trying to load JS files that are not really used and should not be evaluated
If libraries continue to access libraries through global window props, it is going to be hard for the libraries to support multiple ways provide the deps
my implementation works by mapping the (:require ["react" :as react])
to a pseudo goog namespace
That is quite similar to how npm-deps
works
and the "react
” just gets replaced by that alias, so it is basically (:require [shadow.npm.react :as react])
dynamic names are just a mess for npm-deps: goog.addDependency("../node_modules/react-dom/index.js", ['module$home$juho$Source$saapas$node_modules$react_dom$index'], ['module$home$juho$Source$saapas$node_modules$react_dom$lib$ReactDOM']);
yeah sort of … can’t really compare this to :npm-deps
since the code doesn’t actually go through closure afterwards
👋 would it be good to submit a patch to allow (= ^string foo "value")
to compile as (identical? foo "value")
to allow simpler DCE? like the ^boolean
type hints allow unchecked-if