6 ms·

Yeah, after the app grew a bit, I had state scattered here and there. re-frame solves this with a big atom, and avoids expensive rendering every time the big at

by timroy 10y ago

Yeah, after the app grew a bit, I had state scattered here and there. re-frame solves this with a big atom, and avoids expensive rendering every time the big atom updates with subscriptions. Subscriptions hold reactions, which only update if the underlying value changes. The re-frame readme is epic and worth reading just for its own sake: https://github.com/Day8/re-frame https://github.com/Day8/re-frame Not to get off-topic though! I am used to working with dynamic languages, but I really should work with a typed language. Elm looks like it offers many of the benefits of ClojureScript, but with typing as well. Also, ClojureScript lets you write HTML and CSS in your code, but a quick web search indicates Elm may have gone further with incorporating CSS (?).

Skinney 10y ago
Elm incoperates CSS the same way Clojurescript and React incorporates CSS.
- timroy 10y ago
  Thanks, good to know.
pseudonom- 10y ago
Can you talk a little more about your thoughts on one big atom? I've been looking at Redux and they also seem to follow this approach. The re-frame readme quotes the Elm Architecture as justification, but that same document goes on to describe nesting https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting. I come from a Haskell perspective and having one big blob of state sounds to me like it makes your type signatures less informative and increases the scope for error.
- timroy 10y ago
  So, the one big atom solved two problems for me. First, in Reagent/FRP, I was updating a view based on the value of an atom. This meant I had different default values in different atoms. The big atom let me unify where I stored values, and reuse values, without a performance hit. Second, the big atom made storing application state trivial: you can just throw the map/record in Redis or something. However, the big atom is just a big map, and keys can be paired with any value, so it is not enforcing types. From a Haskell perspective (where I understand the program almost falls out of the types you define!), this probably does increase the scope for error. This can be mitigated with Schema (which I never used effectively), logging changes to the console, and being able to see your default map easily (like, there's a map in one file which I load upfront, so I can see what values are there). I'd welcome hearing from anyone with a more advanced or precise use of re-frame state.

by timroy 10y ago

Skinney 10y ago

Elm incoperates CSS the same way Clojurescript and React incorporates CSS.

timroy 10y ago
Thanks, good to know.

pseudonom- 10y ago

Can you talk a little more about your thoughts on one big atom? I've been looking at Redux and they also seem to follow this approach. The re-frame readme quotes the Elm Architecture as justification, but that same document goes on to describe nesting https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting. I come from a Haskell perspective and having one big blob of state sounds to me like it makes your type signatures less informative and increases the scope for error.

timroy 10y ago
So, the one big atom solved two problems for me. First, in Reagent/FRP, I was updating a view based on the value of an atom. This meant I had different default values in different atoms. The big atom let me unify where I stored values, and reuse values, without a performance hit. Second, the big atom made storing application state trivial: you can just throw the map/record in Redis or something. However, the big atom is just a big map, and keys can be paired with any value, so it is not enforcing types. From a Haskell perspective (where I understand the program almost falls out of the types you define!), this probably does increase the scope for error. This can be mitigated with Schema (which I never used effectively), logging changes to the console, and being able to see your default map easily (like, there's a map in one file which I load upfront, so I can see what values are there). I'd welcome hearing from anyone with a more advanced or precise use of re-frame state.