The Desktop UX Summit last week included what I thought was a very interesting topic: Building Maintainable UIs with Flux by Jason Southwell.
He presented an overview of CocinAsync (link to bitbucket) which includes a Delphi implementation of Flux. I wouldn’t do it justice by trying to explain what it is, other than saying that it’s a coding pattern designed with a unidirectional ‘state first’ approach. Think MVC or MVVM, but in one direction only.
I’m curious if anyone else happened to watch this or otherwise has used the CocinAsync toolset.
Footnote: The YouTube link is available, but unlisted, so I hesitate to include that here (as much as I’d like to!). A quick search will give alternatives though.
I haven’t used it but it does look interesting (can you pm me the yt link?). I used redux in a react app a few years back (was just a proof of concept app) and liked how it worked, but you do end up with a lot of boilerplate code (reducers etc).
I kinda use part of the concepts in my Delphi applications - using my VSoft.Messaging library - I use messages for two things
To mutate the state.
To notify when state has changed.
I’m currently rewriting Action Studio (part of FinalBuilder and Automise, an IDE for creating custom actions) - I have a ‘Project Service’ which manages the state (projects open in the IDE) and when ever the project service mutates the state of a project, it sends messages (projectOpened, projectClosed, projectModified etc) which other parts of the application (typically the UI frames) can react to. The messages can have a payload - in the case of the project messages it would be the project object. Also since the messages have the payload/data - I often do not need to hold the state in the subscribing object - I can just use the payload.
State mutation is mostly done inside the Project Service - either by calling it directly or by sending messages to it - or it sending messages out - e.g sending an ApplyChangesMessage which the forms and frames can subscribe to and update the supplied object.
I started out only sending messages to the service but that quickly became unmanageable - a bit like redux imho - the number of message types explodes very quickly.
Since I’m using the Spring4D container, I register a Message Service with the container that wrappers the messaging library that I can inject (or resolve in the case of forms, since spring4d doesn’t really do forms) for sending and subscribing to messages.
I like the messages because it decouples things nicely, and it makes it really easy to reason why something happens - if I see an odd behaviour that happens when I open a project, I’ll just search for the ProjectOpened message handlers and see what they do.
I’m still refactoring and evolving this architecture - so it’s very much a hybrid as I figure out how to achieve what I want. YMMV.
Sounds like you are well on top of this approach. There are clearly many benefits to using messages. I wish I had this knowledge 10 years ago when I was designing one of my apps! Refactoring takes up more time than I’d care to admit.
Spring4D gets a mention in the video. I’ve looked at it in the past but never got around to using it in a project.
I wouldn’t say I’m well on top of it, but I have tried to adopt parts of it that suite my way of working.
I’ve been using messaging since around 2002 but that was mostly for background tasks then - in FinalBuilder the stepping engine runs in a background thread and publishes messages that are consumed by the logger and by the UI. Funfact, the stepping engine can run a lot faster than the ui or the logging (db) so we actually have to slow down the engine to allow other parts of the application to catch up - the ui and the logger (nexusdb) cannot process the messages fast enough.
When we refactored the code for FinalBuilder 8 we started using messaging in the UI code a lot more for managing state changes etc.
Sadly we didn’t apply the same architecture to Action Studio - which is a big homogeneous mess of spaghetti - and I recently needed to make some changes to it for FB9 - after wasting a week trying to decipher that code (written mostly by former employees) I gave up.
I bit the bullet and started fresh - this time I am trying to make the code cleaner and more structured, using dependency injection, messages and centralised state management (kinda like stores, but they have methods). I don’t know if I have succeeded or not yet, but it’s going well.
Every application I have built in the last 15 years is comprised of components that communicate through messaging (with subscriptions set-up in a config file, not in code). Makes development of complex systems an order of magnitude easier, and essentially handles any threading requirements as the components run in their own thread (I call them threaded queues). Pretty much allows me to develop highly multi-threaded applications without using any synchronisation constructs (all my code I then “thread-safe” because it only runs in one thread)
There are clearly many benefits to using messages. I wish I had this knowledge 10 years ago when I was designing one of my apps! Refactoring takes up more time than I’d care to admit.