eholdings app is designed completely different from any other Folio app. eholdings uses:
- data layer versus stripes-connect
- json+api versus json
As a result the app has challenges when integrating with other apps (e.g. tags). For Q1 2019 and Q2 2019, the eholdings app will integrate with several modules/plug-ins, Agreements, Notes. And in the future other integrations will focus on Licenses, Orders, etc.
Spike needs to address the following:
- How can we address Q1 2019 (March)/Q2 2019 (June) integrations of Agreements and Notes?
- Do we need to refactor tags implementation given approach(es) under consideration.
- Which approach is optimal? What is estimated timeframe?
- Which approach will ensure we have Agreements and Notes integration available by Q2.
- please consider reaching out to Matt Jones
Spike Timebox: 12 hours
- Have options for how to implement Agreements integration as defined in backlog user stories. Provide benefits and challenges to these options
- Consider option for mod-kb-ebscojava to be a proxy and work with backend team on estimates
- Provide estimates for options
- Present to team
- SPIKE RESULTS:
Currently UI-eholdings Data layer was build taking into account that all the communication with the back-end is performed through mod-kb-ebso.
The ui-eholdings data layer expect that the response payload follow the JSON API format.
Only mod-kb-ebsco follow the JSON API specification. All other back-end modules follow the POJO format.
In order to be able to communicate with the other module there are two approaches could be taken:
1) This approach is similar to the applied one.
- Add new model
- Add the deserializer
Deserrializer could be added in the '/redux/data.js' extending the 'resolve' action creator, modifieng the payload to fit the JSON API structure.
- Customize serializer
Serializer should be added to the model to fit the required payload structure of the POST/PUT requests.
- Less code modifications/refactoring
- Less flexible approach than elaboration of specific for the request/ side effect epic/actions/reducers
- wired t the current setup of resolver
The described above approach was used in ui-eholdings for the requests to mod-tags.
This was implemented in the following PR: https://github.com/folio-org/ui-eholdings/pull/748
2) Add new epic/actions/reducers
- Data should change through small actions, which are responsible for the small piece of logic.
- Create Epic(RX middleware) which subscribe on needed action and does the request for fetching or updating the data.
- Create Reducer for updating a piece of global App Store.
- Write tests for actions, epics, reducers
- Is flexible. Doesn’t depend on the data type.
- Clear and simple. Is a common React approach for managing the data in the app. The low learning curve for new React Front-End devs.
- Easy to test and debug
- No dependencies and inheritance like in models. The composition is preferable.
- Requires to write boilerplate plate code every time