What Domino Makes Trivial Number One: State Management

Don Mottolo makes a good point in his comment on my recent blog post, that there are aspects of other web frameworks that make it a non-trivial task. This is also really why some people talking about Domino are talking about “mid coders” and “pro coders”. And it’s also why the terms don’t really exist outside the yellow bubble.

The fact is that Domino hides a lot of the complexity of development on JavaScript and Java frameworks. XPages also hid a lot of that complexity too. It’s something I realised stepping beyond Domino into frameworks like Vaadin and React. Yes, there were a lot of similarities to XPages, if you had dug deep into how XPages worked. But there were also areas that Domino and XPages on-the-whole “Just Does It For You”.

One of those areas is state management.

Notes Client

Let’s consider state management in Notes Client. For some years there has been a preference to re-open tabs that you had open the last time you closed the Notes Client. This is an example of state management – your Notes Client retains the state that existed last time you closed Notes. Another is views. When you go to a view, you are at the position of the last document you worked on. Edit and save a document, and again the same document is highlighted, as long as the changes made haven’t removed it from the view.

There is a state store available to you, if you wish. You’ve probably used it without realising that’s what it is. That is notes.ini environment variables. I’ve used it extensively lately for Domino Mobile Apps development. It is basically the equivalent of sessionScope in XPages.

Global variables may be used on a Form for persisting values between various actions. And as I blogged about recently, the “static” keyword in LotusScript also allows you to persist variables between calls to a function.

But on the whole, in Notes Client development, state management is something we just ignore.

XPages

When XPages came along, it also handled a lot of state for us, again without us realising that’s what was happening. State is persisted across component code by “requestScope”, across the life of a page with “viewScope”, across a browser session within the NSF by “sessionScope” and across all sessions for the NSF with “applicationScope”.

There’s also something called the “component tree”. This is where the structure and existing state of an XPage and its Custom Controls is stored – either in memory or on disk, depending on Xsp Properties’ Persistence Settings. Many may not realise, but viewScope is also stored or persisted in the component tree.

But the fact is, this is all hidden from developers and the XPages runtime does it for you. If it didn’t, you would need to make a programmatic call to write viewScope to memory/disk, to write components with their current property values to memory/disk.

Removal of the persistence is also handled automatically for you. You don’t need to make a call to unload an application or session from memory after a certain time or remove the nth component tree. You set properties in Xsp Properties’ Persistence Settings and the XPages runtime handles it all for you.

We first had to handle state ourselves with views, before the Extension Library. If you opened a document and went back to the view, you went back to the first document. There was nothing in-built to go back to the same document, or have everything expanded that was previously expanded. And many developers struggled with that and required something to “Just Do It For You”. That’s why we got the Pager Save State control. And again, developers probably didn’t stop to think what it was doing and how they might build that themselves elsewhere.

The other aspect is when state is persisted. XPages offered great flexibility, with virtually everything being computable. So state tends to be coded on the components themselves. We compute the “rendered” property on the component itself. We don’t update the “rendered” property from the business logic, by getting a handle on the component from outside and calling setRendered(false).

Beyond Domino – Vaadin

First, I should say that I haven’t developed with Vaadin for some time and there have been a number of releases since I last did anything.

Vaadin is a full Java web development framework. Everything is coded in Java, typically with controller classes and “custom controls” (basically a component containing multiple other components – buttons, inputs etc). The components are created in Java, the page built up with Java, and handlers (button click, etc) change properties on components by getting a handle on them and updating them.

This is the key different to XPages. Instead of re-calculating all components’ properties during a page update, it just updates editable values changed in the browser, runs converters and validators, and runs business logic at the point of interaction by the user (e.g. a button click). It’s the business logic that manipulates the properties.

Apart from that the way it handles state has a lot of similarities to XPages. That’s probably not a big surprise, after all they’re both frameworks building on Java servlet technology. But the big difference is that Vaadin apps are coded fully in Java as a standard web application developers whereas XPages applications are built in an NSF with an application navigator that hides the web application structure. And the state management is accessed via classes that have the word “servlet” in their name, not variable names that hide how the state management is done, to simplify it for new non-Java developers. Because of where the developers are coming from and the necessity for simplification of standard technologies, Vaadin developers are probably more aware of what’s happening under the hood.

Beyond Domino – React

With JavaScript my experience for front-end development has been with React, thanks to the session John Jardin and I gave on JavaScript development with Domino at IBM Think 2018. Thankfully John created the React application, but through digging into it, I got an understanding of the similarities to XPages (yes, there are quite a few) and the differences.

One of the big differences was state management. Again, I think the key to this is where the technology is coming from. JavaScript traditionally existed only in the browser, running wholly in the browser, delivered by a web server. State management was not required – everything was in the current browser page. If required, browser cookies or URL query string parameters were used to share information between pages. Think of traditional Domino view URLs, where start, count, categorisation level expand level are passed as part of the URL. No state is retained on the server, state on the browser is handled by updating global JavaScript variables.

When full stack JavaScript came along, suddenly there was JavaScript running on the browser and the server. The server needs to store state in order to minimise what’s being passed back and forth. For mobile devices and applications, written in JavaScript with local storage and remote storage, needing to pass information between the two, again there’s a need to manage state more widely. And with component-driven development, the current state of the component also need handling, potentially updated from various places inside and outside the application (e.g. by a web sockets server). For React, this is where Redux comes in.

But there’s no attempt to hide that you need to store state, there’s a degree of complexity with the code required. For example, see https://github.com/johnjardin/domino-js-masterclass/blob/master/src/react-to-do-docker/react/to-do/to-do-reducer.js. This is understandable, because JavaScript is coming from a standpoint where you would have had to code this yourself and there is no underlying standard that the frameworks are building on, like Servlets in Java. There’s a lot of converting to and from JSON and the need to push / pull from actual databases where required, ensuring that the scope and the database are consistent – and handling inevitable conflicts! And understanding what the current state is where is like a game of 3D chess.

If you understand what needs to happen in state management, it’s a learning curve but manageable. If you’ve isolated yourself from that in Notes and XPages, it’s a massive mind-shift, as Don says.

And there are other aspects that complicate it further, which I’ll come into.

Beyond Domino – Node-RED

Node-RED has state management as well. But to some extent, as a mid-code environment, it does a lot of simplification. There is the msg object that runs through a set of nodes. There are the flow and global objects that share variables across a flow / sub flow and between flows. Similarly, there are config nodes, that store information and are used by multiple nodes. But state is typically dumped if Node-RED restarts.

There is a storage API that can be used to persist state more widely, but that’s something you have to code yourself.

If you’re not using that, state is much more similar to XPages scopes. The flow and global objects are JSON objects, which are effectively the same as the Java maps sessionScope etc. And there is another key similarity that I’ll come back to.

Summary

Don is correct that there is a lot of complexity outside of Notes and XPages. The big change is needing to understand at a much lower level what’s going on. And we’ll see that again in my next blog post.