Extract the state machines into replaceable modules #3356
Conversation
core/lib/spree/core/state_machines/return_item/reception_status.rb
Outdated
Show resolved
Hide resolved
core/lib/spree/core/state_machines/return_item/acceptance_status.rb
Outdated
Show resolved
Hide resolved
core/lib/spree/core/state_machines/return_item/acceptance_status.rb
Outdated
Show resolved
Hide resolved
Allow replacing the existing state machines with custom ones. This would allow easier customization in stores.
cedum
force-pushed
the
extract-state-machines
branch
from
b750f6b
to
7c4f82c
Compare
|
This is a really good idea 馃憤 |
There was a problem hiding this comment.
I really like how this allows customizing the state machine but keeps it simple for stores that do not need to change these things. I'd love to also see some Guides pages update with some simple examples, but it's not blocking. Just let me know if you plan to do so and I'll add a WIP tag to the PR. Thanks, @cedum!
@kennyadsl 馃憤I'll work on it in this PR |
|
I've pushed a draft for the documentation (here's the preview). Instead of describing it for each model, I preferred to add a generic guide under Customizations. |
|
I think it's a perfect starting point, thanks! |
cedum
force-pushed
the
extract-state-machines
branch
from
54ea632
to
2f370ef
Compare
This PR extracts the existing state machines into replaceable modules.
A while ago I took ownership of some PRs that completely removes the state machines from a few models (#3038, #3039, #3040, #3041).
While I fully agree with the rationale behind those PRs, I think that rewriting manually each dynamically generated
state_machines's method might not be ideal.AFAIK, the state machines in these models don't need to be customized for the majority of the shops (please correct me). Also, having different state-related logic implementations for different models could be confusing.
By discussing this a bit with @kennyadsl, we thought that it might be worth introducing first an intermediary step that lets developers tinker more easily with the existing state machines instead of removing them completely.
This will enable the (few?) shops which require a custom state-related logic to provide their own while keeping a standard implementation for the rest. Hopefully, it could also lead to more ideas 馃挕addressing the concerns in the original PR (#3038).
Checklist: