Hi Chanaks, Thank you for the inputs. Yes, the intention is to minimize the re-work and keep the solution to the simplest. But if our approach going to be kind of a re-inventing the wheel (resembles Redux or Mobex) then the best solution for our problem will be using those existing libraries ?
Thanks ~KasunTe On Wed, Feb 13, 2019 at 8:48 AM Chanaka Jayasena <[email protected]> wrote: > 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 > -- *Kasun Thennakoon* Senior Software Engineer WSO2, Inc. Mobile:+94 711661919
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
