Global state

[pepe]

Hello.

Funny thing, as I was developing https://github.com/pepe/showrum yesterday, I came to the edge of what is feasible with simple hash and methods and started to think about how to continue. And in the morning I found scrum 👍. Thank you very much for it, I love OpenSource!

As I was looking into the code, I found that DB is global for the library (and makes it a framework?), which brought to my mind this issue day8/re-frame#107 by @darwin in re-frame (which I was using extensively, but abandon it lately). I am still not sure, if it is actually problem or not, I just want to bring it to your attention.

Again, thank you, I will try to move showrum to scrum ASAP.

[roman01la]

Hey @pepe. Thanks, I'm glad you found this useful :)
I'm also concerned about global state, but don't really know at the moment how do decouple it in a nice way. If you have any ideas, it would be great to discuss here, maybe we can do something about it.

[pepe]

Great, first step I would like to make is to use your lib, and see how it fits my needs.

Thank you again.

[jeroenvandijk]

Hi @pepe and @roman01la thanks for your work. I was pointed to your library by a co-worker, as I was trying to do something similarly yesterday. I have the same idea/approach of what you want and one of my main goals is to get rid of global state (i.e. only at the root of the application).

This is my example code which looks pretty similar to your solution actually, and I swear I just saw your library.

Here is how I avoid global state, by passing my quasi reconsiler during mounting

Hope you see the common intention. Maybe it helps you to develop this idea further. My inspiration is om.next and I hope to combine it's parser and indexer with this approach.

[roman01la]

Hi @jeroenvandijk. So you basically passing the state Atom down through components tree and using it as a pub/sub mechanism to communicate data between components?

[roman01la]

I've been thinking about how to avoid global state and the only solution I see is to pass it directly to every component, from the root. I like this approach because it is explicit. On the other hand this introduces unnecessary dependencies in components and makes it impossible to apply rendering optimizations.

Another way of avoiding global state is to rely on React's Context API, which is usually used to pass data implicitly to every component in a tree. This is how for example Redux works in JavaScript.

[arichiardi]

Hey guys, in the re-frame issue above the general semiconsent was to use the context indeed. Maybe it is time for us to try 😀😀

[roman01la]

@arichiardi Yeah, I think I might go this way. But that's doesn't really matter.

I've been hacking this evening on @jeroenvandijk idea and ended up with a reconciler type which is basically an atom + controllers. Though I'm not sure if this is a good idea to introduce own atom.

(def r (sr/reconciler (atom {}) {:counter curl/counter}))

@r ;; {}

(sr/broadcast! r :init)

@r ;; {:count 0}

(sr/dispatch! r :counter :inc)

@r ;; {:count 1}

[jeroenvandijk]

Ah nice :) So regarding the passing around of the argument. I first tried another approach where I used the child context to forward the reconsiler/atom. Then only at the root level you have to do some magic things with the bindings. I didn't get this to work yet without using the internal react API, but I'm sure there is a way (I can show you this example later). I had the feeling this approach was less clean and that i wasn't sure about the benefits. But definitely still an option. The passing around of the reconsiler feels like how we use component in other applications. That works quite well. We often use a map of services. The reconsiler would be one of the services (if not the only one in this case). My approach in the gist has the disadvantage regarding optimization as the subscriptions are (re)calculated during rendering. This could be fixed (I guess) if you have can add the reconciler directly in the init phase (probably possible via react internals or child contexts), and the rum macro would have to calculate the dependencies in advance not during rendering. Maybe this could also be done by calling the render fn once during initialization to get the info (if one has access to the render fn during init). Some random ideas :) I hope to try some more next week Op za 11 feb. 2017 22:25 schreef Roman Liutikov <notifications@github.com>:

…

@arichiardi <https://github.com/arichiardi> Yeah, I think I might go this way. But that's doesn't really matter. I've been hacking this evening on @jeroenvandijk <https://github.com/jeroenvandijk> idea and ended up with a reconciler type which is basically an atom + controllers. Though I'm not sure if this is a good idea to introduce own atom. (def r (sr/reconciler (atom {}) {:counter curl/counter})) @r ;; {} (sr/broadcast! r :init) @r ;; {:count 0} (sr/dispatch! r :counter :inc) @r ;; {:count 1} — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr_apeAS2F4__i8UcNmDOWyl2pGjeOks5rbidDgaJpZM4L8C3i> .

[roman01la]

Just updated master with a new architecture built around reconciler thing. Also updated an example code, so you can see how it works now example/counter/core.cljs

Notable changes

• Reconciler is a ref type which holds application state (atom) and controllers map.
  A key of a controller in the map is where controller's state will be placed in app state.

  (scrum/reconciler (atom {}) {:counter control})

• A controller no longer has access to a whole app state, instead it will receive only a portion of state associated with a key used to register this controller, when creating reconciler.

Still looking into how to handle async stuff...

[pepe]

I am almost done with the transfer of showrum to scrum (flu got in the way), so I extend it for a new stuff. Great work @roman01la! Highly appreciated!

[pepe]

So after a just quick look into the code, it seems very good. Tonite I will move the showrum to the new codebase.

[roman01la]

@pepe Cool! Looking forward to see what you have there.

[pepe]

@roman01la at https://github.com/pepe/showrum/tree/scrum you can see the version with the latest scrum (which is part of the ./src as it is not yet released). The showrum code sure needs some refactoring, but it is working as intended and is quite big, so we have the good test bed.

Also, I looked through the new scrum code and it seem much clearer to my eyes.

I am very happy with the result! 👍

[roman01la]

@pepe Nice! Do you have any concerns so far? FYI I've published from master as 1.0.0-SNAPSHOT

[pepe]

Thanks. No concerns so far. Truth is, I quite like this super simple approach. And there doesn' t seem to be any speed penalties so far.

The only thing (as you mentioned in the roadmap) is the effects handling.

I think this issue could be closed 😉, thank you very much.