Hi Kasun, I think this is a nice proposal.
But since we are lot concern about the time constraints at the moment, IMO the proposed architectural change will take significant time. For the problem of doing multiple calls to get the API details on each component can't we use the React.Context to pass the API object from HOC. Have a setter to update API object from the child component and call this to update the master state object. We have this already done with 3.0 Store app. But the setter part is not implemented yet. [1] - https://reactjs.org/docs/context.html thanks, Chanaka On Tue, Feb 12, 2019 at 4:49 PM Kasun Thennakoon <[email protected]> wrote: > Adding Amali. > > On Fri, Sep 28, 2018 at 6:43 PM Kasun Thennakoon <[email protected]> wrote: > >> 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 >> > > > -- > *Kasun Thennakoon* > Senior Software Engineer > WSO2, Inc. > Mobile:+94 711661919 > -- Chanaka Jayasena Associate Tech Lead, email: [email protected]; cell: +94 77 4464006 blog: http://chanaka3d.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
