overmind: Breaking changes before official release
After the announcement we have gotten a lot more people testing out Overmind. Especially the Vue and Angular (coming soon) views has gotten some amazing updates. But also smaller details on the API can be improved. In this issue we will list the breaking changes we want to make before the official release:
1. Separate value from configuration
In actions you receive:
const myAction = ({ state, effects, actions, value }) => {
}
This value does not really belong in the rest which is defined as “the configuration” of the app, it maps directly to the configuration. So we want to separate that out:
const myAction = ({ state, effects, action }, value) => {
}
This is more intuitive, as you can think of the first argument as “the context” of the action, pointing to the Overmind instance.
Amount of work
- Refactor devtools
- Refactor website
- Rewrite all documentation (there are a lot of examples)
- The VueX video is wrong… though we can maybe add a note to it instead. I have not figured out how to add like “notes”… maybe we can use this link notifier and say: “API CHANGE” and link to the documentation… yeah, that could work
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 5
- Comments: 18 (15 by maintainers)
Okay, good, I understand what you mean by
helpersnow 😃The sub context here for me is that I think we learned a lot from Cerebral. Overmind has been announced after an experimentation/development phase of over 6 months now. The API is locked. I think we pushed a lot of developers away from Cerebral because of all the changes we were making after the announcement and now we have a bigger responsibility because we have gotten a lot more attention. This makes me extremely defensive on making changes.
That said, even without this defensive default I would still disagree. Derived is a pure function of state. We should not make any changes that makes the derived function impure, which this suggestion does. Import your pure helpers and use them in the derived. There is no need for possibly hundreds of developers to refactor their code because of this. I do not see how this blocks you in any way.
I ❤️ you @gaspard and I feel shitty about working against you when you are inspired, but I do not see how I could ever budge on this. Effects is now a conceptual term in all articles, discussions, documentation, API and videos and I still think it is a really good term that helps developers separate their code in a healthy way. I am sure we would have great discussions on creating a different concept than
effectsearlier on, but this is what almost burned me out with Cerebral. Going back to all articles, docs, APIs and videos… explaining to everyone why we made the changes. I think it is wise of us to acknowledge that the window for these kinds of changes is passed.I wanted Overmind to be a small API surface with clear concepts which people can build upon. I think we have achieved that and now is the time to help people use what we have built, not make more changes. If you want to use
effectsconceptually different that is perfectly okay, but we do not have the luxury of making radical changes anymore. It is not fair to all the others, making changes has a huge cost… something I feel really bad about in Cerebral.I agree with you @christianalfoni. I upgraded (and worked) on Cerebral through so many API changes and type changes and then again with Overmind and we really need things to be cool or we will all burn 🔥😂.
I can live with the way Overmind works now and use this
effectsthing as it is, without needing it inside Derive. It just felt weird having a different argument order and types in Derive from the rest but it is not important.From “baobab” Cerebral, it went from no types, to weird types, to Overmind which is something that is now very easy to understand and use and I am super proud of you and grateful for all the hard work you put into this 🙏. You are my hero !