This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-16
Channels
- # beginners (81)
- # calva (6)
- # cider (21)
- # clj-kondo (2)
- # clojure (62)
- # clojure-austin (3)
- # clojure-europe (3)
- # clojure-italy (20)
- # clojure-nl (39)
- # clojure-russia (4)
- # clojure-spec (19)
- # clojure-uk (23)
- # clojurescript (76)
- # cursive (6)
- # data-science (9)
- # datomic (12)
- # defnpodcast (1)
- # figwheel-main (3)
- # fulcro (8)
- # jackdaw (5)
- # jobs (1)
- # jobs-discuss (18)
- # joker (1)
- # leiningen (2)
- # liberator (2)
- # off-topic (148)
- # onyx (5)
- # pedestal (39)
- # planck (7)
- # re-frame (5)
- # reagent (3)
- # reitit (37)
- # shadow-cljs (165)
- # tools-deps (1)
- # yada (19)
@hobosarefriends just install that specific version via npm?
I wrote some code in shadow-cljs that I want to extract into a reusable library. What is the best way to go about? The code/lib will only be consumed from clojurescript/shadow-cljs itself. I prefer not to compile to a node-library or npm-module which requires explicit exports. Should I bundle it as a jar instead or just symlink the code? Thanks!
I currently recommend lein for that since shadow-cljs doesn't have anything built-in for that yet
I have some boiler plate stuff that I want to reuse. So cljs import/export would be awesome
this is good if you want to use deps.edn https://clojure.org/guides/deps_and_cli#_using_local_libraries
Hi all! I know this is a stupid question, but my keywords are failing me for a google search: const parse = require('csv-parse/lib/sync') how does this translate as a :require ?
https://shadow-cljs.github.io/docs/UsersGuide.html#_using_npm_packages See react-virtualized example
I expected this to work: (:require [csv-parse :as csv]) ... (def parse-csv (-> csv .-lib .-sync)) but .-lib is undefined
so i don't have hard data to back this up yet, but i seem to need to use shift-reload to get markup changes recently. I'll be happy to try to build a simple repro case, but was wondering if anyone had the same issue before i do?
i'm using chrome, and the js console is telling me it's reloading the appropriate modules
i will try to put together a simple proof app - i could totally be doing something stupid, but just wanted to see if that was a known issue.
it happened to a couple people on my team recently, is why i was asking. but we're all working on the same app, so could def be a code problem
I had a number issues after we upgraded to 2.7.x to 2.8.x due to the closure library update. I had to clear my build output and cache
Iāll let @thheller comment because I think if there is an issue, he might want to peek at your .shadow-cljs folder so hold off on deleting that š¬
is there a particular way to invoke shadow-cljs from npm/`node` without a global installation? e.g. in some directory where iāve just npm installād with a package that declares shadow-cljs as a dependency. running shadow-cljs ... is showing shadow-cljs: command not found
FWIW even with a global install it will always use the version installed in the project itself
right, that I do know. Iāve just been wading into building a project as part of a remote pipeline, and theres no global installation there, so the build.sh was failing. Didnāt want to redundantly install it globally. I feel pretty good about the npx addition, I think thatās the secret sauce.
@thheller fwiw, there are no errors - everythign looks just like it should, except i need a shift-reload to get markup changes to show up - i'll build the repro app (if i can). otherwise, if nothing off the top of your head, don't worry about it. thanks.
shift-reload? do you use the built-in dev-http servers? otherwise caching might be an issue? active service-worker?
yeah, sorry - using re-frame, changing some prop on a div (for instance), and it doesn't auto-show-up
if you are doing that you might need to also clear the re-frame subscription cache in that hook
@lilactown do you have a function/macro in hx that will just return a react element?
the whole lib was supposed to be a clever setup for hxf = "hiccup transform" š
kinda got lost along the way
I'm running some benchmarks of cljs react wrappers since I wanted to compare my new one š
@lilactown was the f function one you wanted to rename recently?
react x 3,449,728 ops/sec Ā±2.64% (93 runs sampled)
reagent x 398,044 ops/sec Ā±1.78% (93 runs sampled)
shadow x 1,851,920 ops/sec Ā±3.58% (94 runs sampled)
hx x 50,539 ops/sec Ā±1.04% (89 runs sampled)itās a fair guess š but this is what I want to rename: https://github.com/Lokeh/hx/pull/46
just wanted to get a baseline. mine is faster than react when running without NODE_ENV=production š
the hiccup parsing does kind of a lot. lots of little corner cases itās taking care of right nowā¦
react x 284,902 ops/sec Ā±0.31% (97 runs sampled)
reagent x 173,311 ops/sec Ā±1.83% (93 runs sampled)
shadow x 269,805 ops/sec Ā±1.73% (94 runs sampled)
hx x 42,893 ops/sec Ā±1.29% (91 runs sampled)
rum x 244,721 ops/sec Ā±0.58% (96 runs sampled)well in my trivial example it is, it also has an interpreted fallback. unsure how often that kicks in though
there's also a bunch of things that hx does to rewrite props as a JS obj that could be memoized
would have expected it to be much slower as well given all the vector/map construction
every time I look at :advanced compiled code I'm amazed at the optimizations closure does
@thheller had you tested with Fulcro dom macros as well? I'm curious how it compares to the others
@wilkerlucio doing excellent as expected
react x 281,008 ops/sec Ā±1.15% (96 runs sampled)
reagent x 170,642 ops/sec Ā±1.75% (93 runs sampled)
shadow x 269,498 ops/sec Ā±1.78% (96 runs sampled)
hx x 41,602 ops/sec Ā±1.26% (92 runs sampled)
rum x 244,612 ops/sec Ā±0.27% (97 runs sampled)
fulcro-dom x 262,460 ops/sec Ā±1.40% (95 runs sampled)@wilkerlucio FWIW the (fulcro-dom/div :.card ...) variant only seems to run interpreted and is much slower than {:className "card"}.
interesting, and I think there is no reason for that, this could be generated at compilation time
@U0CKQ19AQ do you see any thing blocking this?
oh, actually, no it can't, maybe the non localized can, but the localized dom needs to see the dynamic var to determine which class is rendered (and use the correct prefix)
updated the benchmark do be a bit more dynamic which makes fulcro slower. probably hitting a slow pass again
react x 87,861 ops/sec Ā±1.61% (89 runs sampled)
reagent x 51,563 ops/sec Ā±2.03% (91 runs sampled)
shadow x 98,100 ops/sec Ā±0.11% (95 runs sampled)
hx x 6,055 ops/sec Ā±9.97% (94 runs sampled)
rum x 80,311 ops/sec Ā±0.33% (94 runs sampled)
fulcro-dom x 29,496 ops/sec Ā±1.83% (87 runs sampled)@thheller the kw variant should be triggering the macro, which should be doing all of the processing at compile timeā¦it should end up raw react in source
Ah, yesā¦if there are children it is impossible to know if the child is a function making props or a child
react x 109,719 ops/sec Ā±0.73% (93 runs sampled)
reagent x 51,251 ops/sec Ā±2.37% (91 runs sampled)
shadow x 97,151 ops/sec Ā±0.12% (97 runs sampled)
hx x 6,039 ops/sec Ā±11.34% (94 runs sampled)
rum x 80,007 ops/sec Ā±0.91% (94 runs sampled)
fulcro-dom x 83,931 ops/sec Ā±1.78% (92 runs sampled)so yes, if you want full performance youāll have to include a literal empty map of propsā¦docs should prob note that; however, the time in those functions compared to everything else is less than 2% of the timeā¦so it is useless to optimize that IMO
perhaps moreā¦I can eliminate path-meta, the client parser, integrate basis-t calcs into db->tree, eliminate the need to render from root. So, one of my complex apps can take 80ms to render a refreshā¦I think thatāll turn into something under 10.
I like the idea too but building something even remotely complex is just super annoying
at least what Iāve played with. Iāve got a useFulcro hook working that lets you use a plain function as a fulcro component
I like that I can use a state hook to get a function that I can then use to do targeted props updates
I can do that with the component-based ones too, of courseā¦but it ends up just a little cleaner because useState doesnāt accidentally collide with other state
@thheller I'm with you on the hooks thing, to me they feel like re-frame subscriptions adopted at react level scale, same scaling issues (hard to reason over time)
my concern is that everything happens in the render function so if you aren't careful about allocation you end up allocating way too much garbage
what garbage do you suspect with useState? Itās stable stuff stored on the instanceā¦Iām not crazy about the āorder dependentā implementation, but as a tool at the js level that we can wrap with better constructs Iām not seeing the problem @thheller
but then Iām defaulting my values to nil, because there is no real component-local state I care aboutā¦Iām seeing it as a way to do āsetPropsā on a component that causes a refresh without colliding with other ppls use of component-local state.
being limited to their hooks sucks since we could do cool tricks with macros to avoid all the stuff that otherwise can become costly
but having worked with it a bit more I guess I'm indifferent. components have their pros/cons just like hooks
Iām hoping using hooks internally in Fulcro will reduce code size. Weāll see. Iām fine keeping the class-based stuff around (and of course kind of have to).
but youāre right, having access to more internals as a documented and stable thing would be nice
so fulcro and shadow ones are quite close