Clojurians Log v2

I have uploaded the devcards demo codes to https://github.com/sniperliu/devcards-sg

the discoverability is a bit better on clojurians. What we’ve been doing from #onyx is linking to the scraped logs in our title

https://clojurians-log.clojureverse.org/clojure-sg/index.html

@lucasbradstreet nice, didn't know about the scraped logs! thanks for adding that in 🙂

Are you still around in Singapore?

Still in Seattle

ah

any plans of returning?

Depends on how the startup goes 😎

just switched from rum back to re-frame for our gaming project

what was the reason for the switch (both to and from)? I've tried a bit of re-frame but not rum

re-frame provide a lot best practice like effects/coeffects for us and save our effort.

since rum is just a component lib

Is Rum is more comparable to reagent then?

I haven’t tried any of those yet but whenever I look at it it seems like it’s all full of state… contrary to what I like about Clojure what am I missing? 🙂

yes, re-frame is bound with reagent

real world have state every where, just how you manage it. even clojure is not pure.

🙂

I meant in the example projects I could always see state all over the place whereas in the Clojure projects you can encapsulate it in one safe place and (almost) never touch it

(that’s an exaggeration but a useful one)

Yeah I noticed that in reagent as well

My ideas on reagent/rum/re-frame: reagent and rum are wrapper library for react, so they are more comparable. Re-frame is based on reagent for writing your SAP in the way it recommends, the counterpart of it on rum is scrum.

Rum vs Reagent: Rum is a thinner wrapper than reagent, it can using "mixins" to mix states into components, it does not have opinion on which way you want to manage states, e.g. you can choose a "static" mix-in for small, cross-project component; a "reactive" mix-in for reactive atom (ratom) based ones. It also encourage you to develop your own mix-ins to handle the lifecycle of states or other specific needs.

While Reagent has more opinion on this, it's core value is "ratom", watch based atom for states.

At First, I liked the flexibility that rum provides, and we wrote a few mix-ins to deal our own components (which using pixi.js undercover is a WEBGL render engine).

While this is handy, but mix-ins turned out not a very functional way and "clojure" way, it more like from javascript's prototype based way. Not very easy to write real independent mix-ins.

So we checked back to the initial decision, read the re-frame documents again (which is quite long, much longer than the code), realized that it may look like a framework, but actually a library composed of "best practices".

The core value of re-frame is a single truth source of app: "app-db", or a monolith atom for all the states. However, it does not forbidden pure-local state, you can still use reagent's type-2 components:

The initial evaluation process we did overlooked it. So it still encourages cross-project reuseable small components.

As many developers noticed, a single app database is very valuable for checking, debugging and most importantly for clojure programmers, for REPL based tool to manipulating a running program.

It also encourages single direction information flow, rather than using reagent's cursor (although you still can use it).

So it turned out most of our problems are already thought by Mike Thompson, and he provides elegant solutions for them.

I strongly recommend to read the docs of re-frame, it definitely worth reading.

oh wow, that’s a lot of to digest, thank you @renewdoit! 🙂 🙂 🙂

maybe you’d want to show re-frame in action during the next meetup? 🙂

Very detailed explanation, thanks @renewdoit!