Hi All,
We are developing the API Manager 3.0 UI applications with React framework
and the data needed to populate the apps are fetched through the product
REST APIs. So far, We haven't use any state management frameworks like
Redux, Mobex etc, so the component states are solely maintained by the
components itself. So far We have used context API, setState method and
props drill down to update and pass the states around. Now we face an issue
in maintaining the API model(JSON object) in the React state and updating
its properties.
For example, In API details pages (i:e Overview, Resources, Endpoints,
Scopes etc... ) We fetch the API object (GET /apis) in each detail page and
update the API properties of the API object in their(Component's)
individual states. The problem here is, API object is not simple flat JSON
object[1], but it contains, many nested repetitive entities, for example,
*corsConfiguration*, *permission*, *operations*,*endpoint*,
*threatProtectionPolicies.* These are having nested JSON objects or arrays
which make it hard to update the object when it's in a component state. And
another problem is, Individual components are not testable, because each
has to do an API call(Yes we can mock it, but still it's not pure as
passing a prop) to get the data it needs to render the UI. For example,
this is the current implementation of the API Details Resources page[2].
To solve these issues, We have come up with the following React component
architecture:
For the nested API object in the state issue, We could use the state
normalization method described in Redux[3][4], to simplify the API model
representation in the React state, and to overcome the API object update
complexities, we could use the Action Dispatchers, Reducers and Store in
Flux pattern. The easiest way to adapt to Flux pattern would be, adding
Redux or Mobx kind of library which adheres to the flux pattern. But the
tradeoff is, It will add some complexity to the React application
development[5].
So IMHO, It's better to implement a simple Dispatcher, Reducer, and Store
for APIM requirements rather than putting the whole library as a dependency
into the app.
[image: image.png]
The above-described implementation would be out of React components, But to
facilitate the data flow, we will adapt the Presentational & Container
component structure[6][7], For example, we could split the API Details
components into 2 types, such as Container-component and
Presentational-components. Where container will be responsible for data
handling and presentational components will render the UI base on the data
passed by the container.
<APIDetailsContainer>
<Overview api={api} />
<Scopes api={api} />
<Permission api={api} />
.
.
.
.
</APIDetailsContainer>
This solution is specifically for the components which it needs to maintain
a nested(complex) JSON object,For the rest of the simple object models,I
think we could survive with basic state management functionalities which
comes OOB with React.
Please feel free to share your thoughts or any issues with the
above-suggested architecture.
[1] : https://gist.github.com/tmkasun/13363c99b2e7565c908de2e98cc7d41d
[2] :
https://github.com/wso2/carbon-apimgt/blob/master/features/apimgt/org.wso2.carbon.apimgt.publisher.feature/src/main/resources/publisher/source/src/app/components/Apis/Details/Resources/Resources.jsx#L138
[3] : https://redux.js.org/recipes/structuringreducers/normalizingstateshape
[4] :
https://egghead.io/lessons/javascript-redux-normalizing-api-responses-with-normalizr
[5] : https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367
[6]: https://redux.js.org/advanced/exampleredditapi#container-components
[7]:
https://redux.js.org/advanced/exampleredditapi#presentational-components
--
*Kasun Thennakoon*
Software Engineer
WSO2, Inc.
Mobile:+94 711661919
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
