This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (15)
- # beginners (32)
- # calva (2)
- # cider (37)
- # clara (1)
- # cljs-dev (47)
- # clojure (177)
- # clojure-boston (1)
- # clojure-dev (2)
- # clojure-germany (1)
- # clojure-greece (5)
- # clojure-italy (13)
- # clojure-nl (2)
- # clojure-sanfrancisco (1)
- # clojure-uk (72)
- # clojurescript (46)
- # cursive (20)
- # datascript (7)
- # datomic (14)
- # devcards (6)
- # docker (1)
- # duct (1)
- # emacs (1)
- # figwheel (3)
- # figwheel-main (151)
- # graphql (2)
- # hyperfiddle (1)
- # interop (3)
- # jobs (3)
- # lumo (2)
- # off-topic (21)
- # pedestal (1)
- # re-frame (9)
- # reagent (25)
- # shadow-cljs (57)
- # slack-help (4)
- # specter (21)
- # tools-deps (53)
- # vim (2)
so is this the recommended way to interface with external libraries? just let them export whatever globals they export in their browser builds and let the closure compiler know about those globals via compiler options?
as opposed to using common js or es6 convention and let the compiler interface with them as if they were google closure modules?
newer versions of cljsjs libraries do the same thing: https://github.com/cljsjs/packages/blob/139e78897a973d53cd5be3788e5ca40f3abf8a90/react/build.boot#L31
so you can use the same method of getting at the js library in the code, regardless of whether you go through cljsjs, webpack/doublebundle or (I think) npm-deps
when i was doing a pure es6 project (without using a bundler), that was the approach i settled on too, but it was a pain to manage manually...
i don't really see the benefit of the whole es6 module system... i have the impression that we would have been a lot better off if everyone would have just adopted the google module system even if they were not using the closure compiler.
just the way the Java Community was deeply affected by the Gang of Four patterns book
If one's house is on fire, they don't care much about not trampling on flowers. ¯\(ツ)/¯
I seem to remember hearing something about that as well, but I’m not so sure because ES6 modules can still close over an initial state correct?
Sounds like a step back for React if it can't be included via the npm-deps support... :/
so its basically give it a try for your dependencies and see if it works, if not use a webpack bundle
if you really need to have the tiniest footprint possible, you can engineer it, but its hardly worth it if you are simply deploying an average webapp
Because we let these tiny little decisions (about module formats for example) accepted as the norm and as a consequence everyone is forced to pay huge complexity tax...
And the effort for them to keep distributing a module format which is compatible with the closure compiler is tiny... And it's a fact, because they were doing it until now
the reasonable expectation of a lib consumer is it works with webpack and rollup, not that it works with GCC
It's more like: because react is being packaged in a non-DCE compliant way, all the other library maintainers will follow suit and nothing will be DCEable.
Except your own app, but that probably doesn't have a lot of eliminateable parts, which will turn the whole compilation process less worthy
I have the feeling that it can seriously undermine Clojurescript adoption too actually
Human history has terrifying examples of what happens when no one steps up and objects...
and folks predicted that when ClojureScript was launched and the choice to use GCC was announced
From my point of view, I’ve accepted that few folks even understand the trade offs that were made and what was lost
But I think I dissagree that this is a recent change that turned against DCE, its just that no one ever cared.
the GCC has been playing catch up with the node module eco-system to try and compile it
if you go back over the versions of react and the GCC sometimes they catch up and can compile it, then they can’t, and then they can again
but even when they can the optimizations that can be done are limited compared to what can be done with the object literal libs that Closure uses
@onetom I’ve been super tempted to create yet another virtual dom library but in either CLJS or Google Closure compatible code.
but I really think someone could take mithril and tailor it to CLJS and get something super quick and tiny
The first time I tried it, it couldn't maintain the cursor position in an input field when I was trying to edit the middle of the text it held, so I declared it immature and potentially fundamentally flawed
Hoplon/UI had this issue and the fix to it was a simple "if el.value changed, then set it to the onchange event's value"
you have to register on change events in React as well depending on the type of rendering that you are doing
I am looking for some pointers on how to integrate my own web server with figwheel-main to server an API without messing with CORS etc.
I’ve found https://github.com/bhauman/lein-figwheel/tree/master/examples/separate-server but I’m not sure how does it relate to figwheel-main?
you just have to ensure that you are serving the compiled clojurescript assets from your new server
most people stumble here because they assume that have to do something funky to make this work
you just have to serve the assets like you would with any other server that you would deploy
So I just serve my index.html and all its references --- but how then do I get the websocket connection to the figwheel server?
Right, so presumably for production I’d have to compile CLJS using some other flag to remove traces of figwheel.
I guess the simplest way would be to run 2 JVMs, one for figwheel, one for my server (then I’d get two separate very clear-cut REPLs too)
Ooh fancy 🙂 figwheel-main is my first exposure for using deps.edn too, I have to read up on the available tricks 😉
I’ll do a POC on two separate JVMs. Would adding a note to the docs about this use case make sense? I also struggled a little bit to get Reagent to work with the hooks, Googling didn’t produce anything obvious. I can try my hand at writing something and submitting a PR?
@orestis I would try using a single process, because then you will get hot reloading of your clj files if they are being watched
Oh, I don’t want that - I usually evaluate directly in Emacs — but it’s worth exploring.
Sure! I’ll give it a go for other members of our team that might find it more useful.
if its not much documentation then perhaps add it to the https://figwheel.org/docs/hot_reloading.html doc
figwheel-main 0.1.9 has been released https://github.com/bhauman/figwheel-main/blob/master/CHANGES.md https://figwheel.org/docs/testing.html