There is a lot going on in the Apple developer community to adopt ideas coming from web development, like from React or Elm. And there certainly is a point where current application patterns have no elegant answers, especially for complex apps and that is: state.
Here I'm trying to find my personal way for find a better solution for this, knowing both sides very well and being happy with some ideas coming from React. But I also don't want to go to far away from what Apple proposals as the standard solution, usually known as MVC.
What is meant by state? I refer to it as another way of looking at the so called model. If we hear model we usually think of a database and therefore of CoreData in the Apple universe. This is the information that influences the view. But more parameters have effects on the view, like: search, filters, view modes, selections, input, etc.
Where does this state usually go to? Well, it often end up being a property in one of many view controllers. But actually it should be part of the state.
How about putting the state on the most top level object that makes sense? For simple app this could be a global value living e.g. in NSApplication. For document based apps this should be NSDocument.
Ok, that's a good starting point. But for the later we need to make any sub view and sub view controller being aware of the NSDocument or the state. You might think this is as easy as going up to NSWindow and the look around for it, but you will pretty sure end up in situations, where you don't have access to the windows, because it isn't already there or already gone.
A better way would be to actually pass a reference around and a good spot for this is
representedObject. So by overriding
NSDocument we have a nice entry point. From there we can go the
window and pass it down via
But wait, views don't have a represented object out of th