This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-02
Channels
- # beginners (98)
- # bigdata (1)
- # bitcoin (1)
- # boot (32)
- # cider (20)
- # cljs-dev (57)
- # cljsrn (130)
- # clojure (93)
- # clojure-dusseldorf (1)
- # clojure-germany (1)
- # clojure-greece (3)
- # clojure-italy (2)
- # clojure-russia (203)
- # clojure-spec (14)
- # clojure-uk (50)
- # clojurescript (127)
- # css (7)
- # cursive (6)
- # data-science (1)
- # datomic (4)
- # emacs (1)
- # events (1)
- # fulcro (8)
- # funcool (12)
- # graphql (7)
- # jobs (1)
- # lein-figwheel (2)
- # luminus (2)
- # off-topic (7)
- # om (16)
- # onyx (4)
- # parinfer (17)
- # pedestal (6)
- # portkey (36)
- # proton (3)
- # re-frame (10)
- # shadow-cljs (140)
- # spacemacs (12)
- # specter (1)
- # sql (1)
- # vim (10)
- # yada (10)
I’m wondering if we should add a new :default
option in ns
for :require
of JS deps to mirror default imports/exports from ES6
there is currently no way to access defaultExport
, it is only available since babel
decided to add a .default
property when rewriting
might be convenient to be able to use default exports other than always writing lib/default
Hmm, should work with Closure already
lib/default
works yes, the questions is whether it makes sense to add :default
to requires as a quick alias method (just like import
supports)
take this example import RaisedButton from 'material-ui/RaisedButton';
from http://www.material-ui.com/#/get-started/usage
(:require ["material-ui/RaisedButton" :as RaisedButton])
you have to use RaisedButton/default
to use it
or (:require ["material-ui/RaisedButton" :refer (default) :rename {default RaisedButton}])
which is horrible 😛
if ES6 becomes more widespread CLJS code will have a whole bunch of x/default
references in code … which is ugly
I think when rewriting ES6 modules, Closure exports the default as "root" object also
Or at least it will probably in future, because that is required for using ES6 from CJS
Or maybe not, Chad's solution in the last comment looks like something else
ES6 has special syntax to refer to a default
export, which is why I’m proposing :default
in :require
to mirror that
Babel etc. have special support for automatically referring to the default export when requiring ES6 from CJS
Hmm, okay, my example case for the issue was other way around, ES6 module requiring CJS
> Adding a default property to module.exports automatically is problematic in some cases:
// Can't add a default property ...
module.exports = undefined;
module.exports = null;
module.exports = true;
module.exports = 4;
ran into this when testing material-ui
and noticed how all the code basically had to use something/default
all over the place instead of something
opened https://dev.clojure.org/jira/browse/CLJS-2376 to track this properly
Fwiw I don’t agree with bloating ns
even more
It already does too much
Also not sure if there’s even an issue here
Already feels like a step up to be able to require these modules
Accessing foo/default
feels like a small price to pay in comparison
The problem is that ES6 code will have quite a lot of those. Just look at any ES6 example out there.
import React from 'react';
import ReactDOM from 'react-dom';
import MuiThemeProvider from 'material-ui/styles/MuiThemeProvider';
import MyAwesomeReactComponent from './MyAwesomeReactComponent';
that alone is 4x React/default
, ReactDOM/default
, MuiThemeProvider/default
, MyAwesomeReactComponent/default
I’m with @anmonteiro ns
has enough stuff - just not that excited about small affordances like this
You are right @dnolen Even though the main README still says Java 7, this did it https://github.com/google/closure-compiler/commit/e9a778d3abdd73e42bc75c295d0210992a97046b#diff-600376dffeb79835ede4a0b285078036