Open Noah-Silvera opened 2 months ago
@kennyadsl @adammathys curious on your thoughts here/not sure who else to tag to take a look. Feel free to tag someone else if it's more appropriate
@Noah-Silvera thanks for working on this. For the breaking-change concern, I think we can assume that if anyone changes the method's signature in their Custom Coordinator, they also have some tests for their custom code.
This looks like a really solid proposal @Noah-Silvera ! How far along is your draft PR and what else do you think it's missing?
Our draft PR is coming along nicely:
coordinator_options
as an attr_reader
in all of the coordinator's collaborating classes.
Quick Link to example implementation
Desired Behavior
The problem
It's very useful that the simple_coordinator can have so many of its internal classes configured. However, they can only be configured for one set of hardcoded behavior, based on the two input values, an order and inventory_units
If you want the coordinator to behave differently in different scenarios e.g, the admin and the frontend, then you have to start getting creative. The simple_coordinator (and all its configured classes) in their current state can only react to the state of the order and inventory_units argument, or they can react to globally set state (which is not a great pattern).
Currently, the simple_coordinator is only called in two places in Solidus: during exchanges, and during creating proposed shipments. However, it is reasonable for a complicated store to want to build shipments in other scenarios.
One workaround to getting the coordinator to behave differently in these different locations is to include any arguments that you want to pass to the coordinator on the order as an attribute or database column, and then read the order attribute in your configured custom class. However, this isn't even a perfect workaround, because not every configurable class is passed the order (e.g. the location_sorter_class). To truly have the coordinator behave differently in different locations you need to do minor to extensive monkey patching
The Plan
We propose addressing this problem by allowing generic options to be passed to the simple coordinator, which are then passed down to each configurable class. This means that any caller of the simple_coordinator can customize the behavior it wants through these options and configuring the extensible classes that the simple_coordinator uses, such as the
location_filter_class
.We have an example of what this implementation could look like in a fork here
This for example, allows for customizations like shipment building behavior that is specific to the admin, where a admin user could be allowed to rebuild shipments with a stock location that is not normally available to users.
Concerns
This is however a breaking change for certain consumers of Solidus. Since this change adds an argument to the constructor of the following classes, if a consumer of solidus has a.) configured their own custom class and b.) overrod e the constructor of their own custom class then their custom class could break. However, this error will cause shipment building to fail, so it should be very obvious to spot and correct. Additionally, there were few reasons to override the constructor of these configurable classes unless you had also overridden the simple_coordinator, as you did not have control of the arguments passed to these configurable classes.
inventory_unit_builder_class
location_filter_class
location_sorter_class
allocator_class
estimator_class
e.g. a custom configured stock location filter like this would be broken
However, initializers like this will be fine, as they implicitly pass the original arguments: