Firstly, single source of truth does not mean storing everything in one object. It means that a single element of data is not stored in more than one place. It also means that data which can easily be derived from other data is not stored separately.
Okay. I thought it meant that you get your data from one place. For example (keeping the web app theme) if I have a component class that has its own private state, recieves some properties and for some reason gets stuff from a global variable, then the current state (the truth?) of an instance of that class does not come from a single source.
How would you unit test such an object?
I don't know how you unit test an object.
That said. Isolation is our friend in this case. We go the Elm/Flux way, we have functions with diferent roles. The ones that produce new state only recieve a piece of the global state, and then we have another one that is responsible for combining the new modified piece with the global state.
In theory this sounds nice, we have updates without side effects, dumb views that just show stuff, and ideally one function that can actually change the global state.
use a database as a replacement for global variables
Oh, no, none of that. That is not what I meant when I mentioned firebase. I was thinking in the idea of treating a global object (in memory... in the browser) like a database, then remembered that firebase uses a json object.
Ok, it seems like I misunderstood some of the things you wrote. I have to say that I don't do a lot of front end development with Javascript.
It certainly is not a good idea to store a property that is used by multiple components in each of the component objects. But is it really the only alternative to store all of these properties in a single giant object? Can't you classify or group the properties somehow and create an object for each of these classes?
This will make the objects smaller and easier to handle.
It will also allow you to assign meaningful names to them and make the code more readable.
You will probably not use each property in each component. So splitting them up will also reduce the amount of dependencies.
But is it really the only alternative to store all of these properties in a single giant object?
It's the only one I can think of.
What I want is to remove all the state from every component.
So I can write my components like this.
functionSomeView(state,actions){// optionally some setup step... but not too muchreturn// awesome stuff}
For the state management could be a pattern like the ones described in here or here, or any other suggestion. Those are not exactly what I want but they are really close.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Okay. I thought it meant that you get your data from one place. For example (keeping the web app theme) if I have a component class that has its own private state, recieves some properties and for some reason gets stuff from a global variable, then the current state (the truth?) of an instance of that class does not come from a single source.
I don't know how you unit test an object.
That said. Isolation is our friend in this case. We go the Elm/Flux way, we have functions with diferent roles. The ones that produce new state only recieve a piece of the global state, and then we have another one that is responsible for combining the new modified piece with the global state.
In theory this sounds nice, we have updates without side effects, dumb views that just show stuff, and ideally one function that can actually change the global state.
Oh, no, none of that. That is not what I meant when I mentioned firebase. I was thinking in the idea of treating a global object (in memory... in the browser) like a database, then remembered that firebase uses a json object.
Ok, it seems like I misunderstood some of the things you wrote. I have to say that I don't do a lot of front end development with Javascript.
It certainly is not a good idea to store a property that is used by multiple components in each of the component objects. But is it really the only alternative to store all of these properties in a single giant object? Can't you classify or group the properties somehow and create an object for each of these classes?
This will make the objects smaller and easier to handle.
It will also allow you to assign meaningful names to them and make the code more readable.
You will probably not use each property in each component. So splitting them up will also reduce the amount of dependencies.
It's the only one I can think of.
What I want is to remove all the state from every component.
So I can write my components like this.
For the state management could be a pattern like the ones described in here or here, or any other suggestion. Those are not exactly what I want but they are really close.