Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
/
Spike: [UIOR-156] Leveraging the existing create item/holding forms from orders/receiving
Current ui-plugin implementations mostly used for displaying/selecting entities from list. I think it's enabled because usually in ui-modules list components implemented as Containers - have its manifest, resources, etc. So ui-plugin-find-vendor just renders a Modal with Vendor's list component inside, passing down corresponding callbacks (selectRow and others).
On the other hand, forms are usually implemented differently - as controlled components, passing to them data loaded from back-end and callbacks with code to call save API.
I believe that one of valuable attribute is to make as less changes to existing ui-modules code as possible, so I see only one way: ui-plugin-create-item should be Container component, to whom user passes required properties (instanceId, locationId for example), it loads everything required to ItemFrom ui-inventory component from back-end and passes it down, as well as callback with POST API call to save new item. In this case no changes required to ui-inventory, but ui-plugin-create-item contains some business logic to fetch and post data (so dependency on okapi interfaces is introduced).
According to slack thread there are plans to leverage edit of various FOLIO entities in a more common way across the whole platform. But since they are mostly long-term I think we can come up with current solution of using plug-in stripes system to reuse ItemForm of ui-inventory module. However, in comments Zak suggested to change my solution - to leverage ItemForm component from ui-inventory. I think we need to choose from these two ways. I'll attach diagrams with both ways as well as Pros and Cons of each.
My way, Pros:
no changes required in ui-inventory;
lest time required for implementation, since code is ready.
Cons:
Tightly coupled with ui-inventory code, so it depends on changes inside it. I think this could be partially solved with tests coverage in ui-plugin repo, so we can see if it's OK to work with future ui-inventory versions on the build (release) stage.
Zak's suggestion Pros:
ui-plugin-create-item is independent from ui-inventory and contains all things required to create item (no tight coupling on other ui-module);
Cons:
changes required to ui-invenotry (to use newly created plugin);
more time consuming in this case: to implement solution and check that no duplicated API calls to fetch data in Invenotry forms, etc. (may be important to Acquisitions PO);