React SDK for Loopback

Goals of this document:
 

• talking about an implementation of an HTTP API for fetching data from a Loopback Application
   
• show pros, cons and issues of having Actions and Stores as a Flux like implementation in our Client SDK
   
• make some proposals of code for all the solutions

HTTP API

We could create an HTTP API starting from the Angular SDK, using it as a code base example.

Our API should provide to developers the ability to call each model's method of our LoopBack Application, checking and validating parameters and request body data.

The best solution in order to doing this, is to create an HTTPInterface, that works as a base class for each model.

HTTPInterface

HTTPInterface

Model1

Model2

Model3

Models are instances of HTTPInterface

HTTP API

Models are simple instances of the HTTPInterface. Each model have to provide the following informations to makes the HTTPInterface class able to work.

- model name

- base url

- actions

Models

HTTP API

Model's actions ar object that describe the requirements for an action call. Our HTTPInterface class use these informations in order to make the call to the LoopBack Apllication, checking url slug, LoopBack Auth mode and the request body data object.

Model's actions

"actionNameUsedAsMethodName": {
    url: '',        // url of the action
    method: '',     // http method
    data: {
        paramName: type
    }
}

HTTP API

The LoopBack SDK is a container that could contains all the API, the HTTPInterface, the LoopBack Auth class and other informations such as the base url of the app.

We could use this container into the browser or with Webpack or other compilation tools using node's require( ) method or ES 6 import, providing it as a module (like lodash, well organized) or as a global object in a compiled version made by the LoopBack SDK CLI itself.

The LoopBack SDK

REACT AND FLUX

Providing the Stores for React with the Flux pattern is great goal, but a even a big problem.

Pros:

simple usage; a lot of predefined implementations like pagination managment, loading state, permissions, relationships, ecc...;

Cons and issues:

combine them with flux frameworks; having one store for a model and doing all the views and data operations with that store

Provide Stores

REACT AND FLUX

Suppose we have Product store, Cart store, Order store and User store.

The Cart Component shows only the Products in the Cart. The Orders Component shows all the orders of the logged in User with Products quantity for each Order.

- How can we have one store for one model with different data rapresentation in components?

- How can we manage relationship and load data when a store requires another store to load new related data? How could be the load order? If we have a Users list component, loading another User required by a Product could change the User list visualitation even if we wouldn't render that User.
- When we have to load related data (for a relationship)? We cannot give the store this responsibility!
 

Stores issues example

REACT AND FLUX

We could create one store for each model and actions as the model's actions.

We could try to use these stores with React using a decorator that pass the data in the props object of the React component.

We could manage relationship using a Relay like syntax, specifing what are the datas we want to download. Each store download the data when it's required.

Solution 1

REACT AND FLUX

Solution 1 Example

@LoopbackConnector({
    'products[20]': {        // download products, 20 items per page, [] means that we want a collection
        'user': { }          // download product's users, belongsTo relationship example, single object
    },
    'another_model': { }    // another model, not with relationship
})
class ProductsList extends from React.Component {
    componentDidMount: function(){
        this.enableRealTimeSync( );        // use this to have real time updates from loopback with socket
    },
    render( ) {
        // check loading state using this.props.isLoading;

        // use this.props.products for products data
        
        // use this.props.products[ index ].user to get the product's user

        // use this.props.another_model

        // use this.LoadMoreProducts( ) to load more products, step of 20

        // use this.addProduct( { } ) to add a product

        // other actions as component method, added by connector decorator
    }
}

REACT AND FLUX

Solution 2

We could simply let's developers create their own store using our LoopBack SDK API.

So this would means that the SDK is independent from React.

This way we have the SDK not care about whatever Fulx implementation.

The API calls could be done into the actions of the Flux implementation that developers are working with.

We haven't to provide any stores, dispatcher and actions...

REACT AND FLUX

Solution 3

Provide Solution 1 and Solution 2 together.

Developers who haven't any FLux implementation could use Stores, Actions and Dispatcher created by the SDK.

Developers that have a framework yet, could use only the API and fetch data with them.

We have to solve all the problems of the Solution 1, but this could be the best way.

FINAL CONSIDERATION

Take care about:

​- today, all the developers that want to develop an App that has to interact with a Back End and with datas, will never create it without a Flux implementation framework (doing this only if the App is small or an example)

- easy is good, but having more control is cool!!

- don't do architectural choise instead of the developers that would use the SDK, only provide to them the way to make the best choice

Thank You for watching

Luca Colonnello

luca.colonnello91@gmail.com

https://gist.github.com/LucaColonnello/55ffd0a311bbf64becc1

Code proposals: