Clojurians Log v2

I don't mind they steal the ideas

I mind that they don't make it well

clearly starts with the problems I've also been repeating non-stop, even here 1. components sharing state only through violation of encapsulation 2. no namespaces

and then implements a half-hearted solution

why?

if hooks were namespaced, you could use them anywhere, since the order wouldn't matter anymore

simply put, the fact that js can't talk about paths in a nested collection efficiently is its biggest weakness

so they won't conflict? 🙂 you need indexed access for performance

https://news.ycombinator.com/item?id=23185451 this has my attention

The trick seems to be some kind of root context with a ref scoped from the name of the atom... That way it is scoped to the tree.

it explains a lot if it is for the server, thanks @dominicm

Am I the only one who doesn’t care for the server render part?

I have had similar thoughts, but I wouldn't voice them quite like that : ). It's all about UX in the end, it is worth having fast first screen which means that it's good to be able to take your app and render it on the server and send it as html while the actual thing is loading in the background. If you don't care for those miliseconds then it's much easier to move all UI to the client and just be an api consumer.

Some projects need it more than others. Particularly when building outside of only application.

"outside of only application"? I almost understand it 🙂

I guess something that is a public thing?

IIRC, search engines also weren't very good at crawling SPAs until recently (even with proper sitemaps and routing)

I was referring to the "A" in SPA. If you're doing pure SPA, then you don't care. If you have a mix of public facing content you're usually more inclined.

Search engines still aren't very good, despite what they claim.

yeah and in general downloading 3mb of compressed JS is still a horrible experience

I really like the idea of selective hydration with mostly static content

it’s what I built at my previous employer on top of CLJS, but it was all very manual

Part of me wonders if I'm doing my current project wrong & we should go back to fully static w/ progressive react enhancement for tables, etc.

a problem with CLJS specifically is that CLJS is awful for progressive enhancement since the core library is so many bytes

Yes. But who'd want to write in something else?

you get a lot of bang for you buck, but it’s still a lot of bucks

haha that’s why I’m still around 😛

Admittedly, my personal values are compromised by Cljs. That is, I think LibreJS is a great idea & cljs really compromises it.

But this is my inner freedom hippy coming out :)

I dream of a lisp-y, repl-y, immutable-first-y lang that doesn’t come with all the bytes. alas, I don’t know if it’s possible

but the costs of CLJS weigh on me every day

You carry this heavy burden on your shoulders? 😁

Admittedly, I've never seen a bundle as big as ours & I'm pretty sure it's mostly from node_modules.

I'm just changing our build to be :bundle, and I'm hoping to see some benefits from that.

Maybe I can run some of our npm deps through closure for example.

Or maybe just having webpack know about the whole build will solve my problems? Not sure.

i am not sure if people see what babel plugins look like size wise

the biggest downside to :bundle AFAICT is that you can’t code split your node_modules with your CLJS code

async regenerator or core-js

or at least, it’s a very manual process

it was always very manual, I heard a lot how closure was the state of the art in code splitting and then I looked it up and you had to manually write the config files. And even today webpack either wants you to use some completely custom built hack around dynamic import() modules which may or may not follow the standard in module resolution logic, or you have to write the splits manually

@lilactown maybe with some webpack config, not sure. We aren't doing that yet, so future Dominic can worry about that.

By then David might have fixed it :)

hahaha

Makes sense :) Now we have a jumping off point to go towards that!

shadow-CLJS with code splitting is pretty trivial. I pushed Vega to its own bundle which was 1mb...

yeah, that’s a big reason I don’t see myself migrating off of shadow-cljs anytime soon

Just skimmed a bit in recoil’s source. It’s ... a lot.

yeah

I only did it on mobile so I won’t pass judgement yet. But I just wonder if just building on top of IWatchable isn’t enough.

It seems recoil “hangs” the state inside the component tree (you need a RecoilRoot component wrapper), so that’s a major difference between that and module-level mutable state.

The “selectors” stuff is just derived data with dependency tracking, which also seems easy to do (esp. if atoms need to be keyed with globally unique identifiers).

Yep. It's the same story as redux :) clojurescript has a lot of this built-in

The main thing I want to see is how they deal with suspense. They have a “Loadable” thing for suspending values, and they seem to be tracking nested loadables too, but the “easy” api seems to be always returning actual values, not Loadables.

Their various hooks seem to be doing a lot of stuff - 4-5 useEffect calls

Hm, watching now the recoil video. The application that the guy is building is (I think) at the far end of SPA. A ton of data, a ton of components, plugins that affect code splitting etc.

I still find it frustrating that to do something like recoil you need to reach into unstable/undocumented React features. (Batched updates, priorities etc).

But at the core idea is mutable shared state propagated via hooks so leaf components can rerender individually.

Which is what I’m trying to do with reseda so I’m happy

yeah I think scoping the state to the component tree vs. truly global is the most interesting design decision

https://twitter.com/brian_d_vaughn/status/1261373167928397824?s=20

I’ve been working on something that’s similar sort of reactive, incremental dataflow but my goals so far have been to help with state that lives outside the component tree

I’m interested to see if there’s a way to design something that could handle global state and state scoped to individual trees

What’s the point of scoping state ton component trees? Testing/DI?

Yep. Devcards, stuff like that.

I quite like that idea - taking the name of the state and scoping it to the tree by registering the name behind a facade. You need a custom swap! then though, which is a shame.

testing, DI, and SSR

yeah the biggest design problem is you need some way of scoping mutations

that isn’t gross to type 😛

(send! scope ref inc) is a lot to type/remember

(with-scope scope
  (send! ref inc))

or, you could scope a ref at creation, so something like:

(def scope (create-scope))

(def ref (create-ref scope 0))

(send! ref inc)

That’s truly mutable scope though, right? Not even an event dispatch :)

I’m just happy that Clojure gives us enough primitives to build these things in the app.

events are just a different kind of message to send 😉

yeah, too low level