Would it be possible to upgrade the jmix-frontend code to depend on mobx 6.1+ (and mobx-react 7.x) instead of mobx 5.x?
“mobx”: “^6.1.7”,
“mobx-react”: “^7.1.0”,
Reasons to upgrade to 6.x then 6.1 are mentioned in the links below but primarily, makeObservable(this) (or similar) should be called in constructors now for classes instead of relying on decorators alone; some undefined behaviour is better defined; and there are other breaking changes too:
What prompts me to ask this question is that I’ve changed some front-end code that uses the latest cuba-react (7.x) to use the latest version of mobx and I’m having trouble with MainStore’s observable state. It seems that my options are:
- continue debugging and trying various configuration options, to see if I can work around the issues without any code change to cuba-react (or jmix-frontend)
- fork cuba-react-* to upgrade its mobx version
- try to move early to jmix-frontend (but not backend, so I hope CUBA 7.x backend and Jmix 0.x frontend are compatible), then fork jmix-frontend to upgrade its mobx version
- revert my frontend code back to mobx ^5.13.0 and reluctantly stay on this version until Haulmont decide to upgrade mobx. Also worry about keeping up to date with libraries such as mobx in the future.
I don’t like the options I have. I’m keen to stay aligned with the agreed roadmap.
From a broader architecture perspective, things move fast in the JS ecosystem, so if Jmix depends on an older version of a key library such as mobx for state management, then if a developer builds a front-end based on the official jmix-frontend modules and Jmix documentation and chooses mobx for their state management, their choice of mobx version may be constrained by Jmix.
Ensuring that the latest version of jmix-frontend always depends on the latest version of mobx seems to be the easiest solution. Alternatively, given how little state is actually stored in MainStore (so far), perhaps the dependency on mobx could be eliminated entirely, by replacing the stateful code with vanilla state-management based on React Context + a redux-like store+dispatch mechanism.
I thought it was a good time in Jmix’s evolution to raise this question. Or, perhaps simply to seek advice.