Hacker News new | past | comments | ask | show | jobs | submit login

> You wouldn't... stick the whole app state in a global variable.

Huh. I thought this is what Om Next did to great success.

* https://medium.com/adstage-engineering/realtime-apps-with-om...

[edit] i misunderstood your argument. Your not implying a single state is bad, your saying their is nothing in python to deal with it.




I suppose. When you update and depend on a global atom your functions aren't pure, at all, in any sense.

Why are you even using FP at that point?

Global application state should be represented in a single root storage; the application data store (ie. database), and the interactions with it should be controlled and sanitised.

If you have a thousand little places across your code base updating and reading from the database, that's horrible code too, in java or in clojure...

Modern UI frameworks are carefully controlled access and update to the display state for a UI; they happen in a controlled and orderly manner specifically to prevent the chaos you get otherwise; if not, you're doing it wrong.

This section in the om docs covers their solution, which is quite elegant: https://github.com/omcljs/om/wiki/Quick-Start-(om.next)#glob...

(notice, you don't just reach out and update atoms directly by hand; there's nothing wrong with having a global application state; that's a good thing, but directly interacting with it is not)


You were closer to it the first time: it's usually a mistake to stick your whole application state in something resembling a god object. The client-side of a single-page application might be an exception under some circumstances when the language provides sane tools for dealing with it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: