[APIM 3.0.0] Handling complex JSON objects in React state

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[APIM 3.0.0] Handling complex JSON objects in React state

Kasun Thennakoon-2
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, corsConfigurationpermission, 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.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.

--
Kasun Thennakoon
Software Engineer
WSO2, Inc.
Mobile:<a href="tel:%2B94%20711661919" value="+94716481328" style="color:rgb(17,85,204)">+94 711661919

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM 3.0.0] Handling complex JSON objects in React state

Kasun Thennakoon-2
Adding Amali.

On Fri, Sep 28, 2018 at 6:43 PM Kasun Thennakoon <[hidden email]> 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, corsConfigurationpermission, 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.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.

--
Kasun Thennakoon
Software Engineer
WSO2, Inc.
Mobile:<a href="tel:%2B94%20711661919" value="+94716481328" style="color:rgb(17,85,204)" target="_blank">+94 711661919


--
Kasun Thennakoon
Senior Software Engineer
WSO2, Inc.
Mobile:<a href="tel:%2B94%20711661919" value="+94716481328" style="color:rgb(17,85,204)" target="_blank">+94 711661919

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM 3.0.0] Handling complex JSON objects in React state

chanaka jayasena
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.


thanks,
Chanaka

On Tue, Feb 12, 2019 at 4:49 PM Kasun Thennakoon <[hidden email]> wrote:
Adding Amali.

On Fri, Sep 28, 2018 at 6:43 PM Kasun Thennakoon <[hidden email]> 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, corsConfigurationpermission, 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.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.

--
Kasun Thennakoon
Software Engineer
WSO2, Inc.
Mobile:<a href="tel:%2B94%20711661919" value="+94716481328" style="color:rgb(17,85,204)" target="_blank">+94 711661919


--
Kasun Thennakoon
Senior Software Engineer
WSO2, Inc.
Mobile:<a href="tel:%2B94%20711661919" value="+94716481328" style="color:rgb(17,85,204)" target="_blank">+94 711661919


--
Chanaka Jayasena
Associate Tech Lead,
email: [hidden email]; cell: +94 77 4464006

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM 3.0.0] Handling complex JSON objects in React state

Kasun Thennakoon-2
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 <[hidden email]> 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.


thanks,
Chanaka

On Tue, Feb 12, 2019 at 4:49 PM Kasun Thennakoon <[hidden email]> wrote:
Adding Amali.

On Fri, Sep 28, 2018 at 6:43 PM Kasun Thennakoon <[hidden email]> 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, corsConfigurationpermission, 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.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.

--
Kasun Thennakoon
Software Engineer
WSO2, Inc.
Mobile:<a href="tel:%2B94%20711661919" value="+94716481328" style="color:rgb(17,85,204)" target="_blank">+94 711661919


--
Kasun Thennakoon
Senior Software Engineer
WSO2, Inc.
Mobile:<a href="tel:%2B94%20711661919" value="+94716481328" style="color:rgb(17,85,204)" target="_blank">+94 711661919


--
Chanaka Jayasena
Associate Tech Lead,
email: [hidden email]; cell: +94 77 4464006


--
Kasun Thennakoon
Senior Software Engineer
WSO2, Inc.
Mobile:<a href="tel:%2B94%20711661919" value="+94716481328" style="color:rgb(17,85,204)" target="_blank">+94 711661919

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture