A minimalist object observer that works with React hooks.
npm install pojo-observer   !npm !NPM
useObserver hook.``jsx
import useObserver from 'pojo-observer'
// It's up to you how the inject the subject. Perhaps use depedency injection + a composite root
export default function GalleryUI({gallery}) {
// Place the hook at the top of your component just like any other React hook
useObserver(gallery)
return (
<>
Image = [{gallery.currentImage()}]
And this POJO:
jsx
export default class Gallery {
constructor() {
this._images = []
this._selectedImage = 0
} nextImage() {
if (this._selectedImage < this.images.length - 1) {
this._selectedImage++
}
}
previousImage() {
if (this._selectedImage > 0) {
this._selectedImage--
}
}
addImage(image) {
this._images.push(image)
}
currentImage() {
return this._images[this._selectedImage]
}
}
`And now any time a value inside the POJO changes, the
hook will re-render the component. Sweet!Bonus: You can test the heck out of the interaction now without having to mess with any UI testing libraries.
$3
Now let's assume we have some async function on that object happening. `jsx
// ... truncated for brevity
constructor() {
// ... truncated for brevity
setInterval(this.nextImage, 1000)
// ... truncated for brevity
`
Yes yes, never put a setInterval in a constructor. But say you have an external event that updates the model, well, the React component will update. Sweet!$3
You can also add as many other hooks like as you like as follows:`jsx
// ... // You can have effet react to specific queries
useEffect(() => {
console.log('effect currentImage()')
// since you have commands, you no longer need to dispatch events with reducers.
// You can work with the POJO directly and handle all complexities there
// gallery.doSomething(...)
}, [gallery.currentImage()])
useEffect(() => {
console.log('effect images')
// gallery.doSomethingElse(...)
}, [gallery._images]) // you can also access member variables directly since the command will trigger a rerender, though it's advised you don't do this as it couples your view to your POJO. It could be useful for debugging.
// ...
`How about nested objects, arrays, and arrays of objects?
They work :)This library is a _minimal_ observer pattern implementation that takes in a POJO as a subject, instruments it, and performs callbacks when the subject has changed. It's not opinionated at all and allows you to use it however you see fit, like choosing the event library to add (or not).
It's also tiny at around ~4k minified.
While working with clients and seeing how complex UI's have become, the question of "is it possible to do DDD in the UI?" kept coming up. We've had great success at helping clients do BDD, DDD, and Clean Architecture in the back-end in order to reduce complexity, increase quality, and improve speed and maintainability (_shameless plug for our consulting services here_), so we wanted to see how to do this in the front-end.
The following inferences were made:
* Part of the BDD approach is bring people together to collaboratively come up with specifications that articulate the problem/solution domain as rules and examples
* Part of the DDD approach is to model the problem/solution domain using aggregates and services that enforce the said rules and carry out business logic required for said scenarios
* Part of the Clean Architecture approach is having concentric-rings layers where the inner layers contain the domain model and use-cases, and the outer layers contain the interfaces and frameworks.
In the world of front-ends, the above inferences result in the following implications:
From BDD:
Bring designers, developers and testers together to discover and reason about a UI with a particular focus on user interactions*, and record the outcomes as either domain or component specifications (_shameless plug, for our XSpecs tool here_)
* Use the behaviour defined in the specifications as examples to drive out the design of the system with a strong focus on automated testing
From DDD
Create a domain model from the specifications. In particular, the focus here is on the interaction* domain
* Use aggregates and value objects to encapsulate an abstract interaction model
* Use domain events to communicate between different interaction aggregates
* Use services to orchestrate across interaction aggregates and remote systems
* Use repositories to talk to back-ends
From Clean Architecture
* UI layer - components that show provided values and invoke actions onto a controller
* Controller layer - Takes actions and translates them into something the use-case interactor can deal with
* Use-case Interactor layer - This is basically either an aggregate root or a service from DDD
_Side notes:_
* _It may make sense to have the UI layer and the Controller live in the same file, even though they are different layers, as long as the separation of concerns is applied._
* _It may not make sense to have a controller at all in some cases and to have the UI layer connect directly to an interaction domain object_
But in order to do any of the above, one has to completely decouple the presentation layer from the layers beneath. And while it's possible to do so with the right coding practices, we found there was a lot of boilerplate in binding data to the UI. If we could somehow just focus on the interaction modeling and then plug a UI on top that requires minimal boilerplate code and is highly decoupled, that would allow us to move fast and to have highly testable code. Moreover, it would not lock us in to any framework.
This is why this library was dreamt up.