Single source of truth, how good/bad can it be?

Specifically in the context of a web application, how good or bad would be if we store everything (yes, everything) in one giant object? No private state anywhere.

Stuffs like the Elm architecture and the tons of state management thingies that are based on that idea make me hope. I like that they allow you to write a "view" as a function that only depends on its input. But people in the javascript world just treat it as a convenient way of passing state between components that are not "close" to each other.

Another thing I can't stop thinking about is that a firebase database is a json object. Putting a lot of things in objects is not that crazy.

Comments

[Frank Puffer]

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.

Secondly, having lots of data in one objet is a very bad thing for sure. How would you unit test such an object? The number of test cases increases exponentially with the number of mutable variables in this object. This will make it almost impossible to fix bugs.

So what about storing lots of data in a database? That's fine when you treat the database as a kind of I/O device and only access it in defined modules of your code. However I have seen designs that use a database as a replacement for global variables and believe me, it was no fun at all to maintain that code.

[Heiker]

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.

[Frank Puffer]

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.

[Heiker]

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.

function SomeView(state, actions) {
  // optionally some setup step... but not too much

  return // 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.