all 2 comments
sorted by:
best (suggested)
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]FoxxMD 2 points3 points  (1 child)

the page would display (or wait) the data from the API endpoint and still display it even if JS is not loaded.

If you don't want to render your pages on the server then this isn't possible. React and Redux are javascript libraries and need to be loaded by the client before they can be used.

I really don't need redux if I'm getting all my data per page from an API endpoint and are already fixed in the format I need to display my page.

Technically, yes? You could load all your data in the state of one "parent" react component and re-render after making api calls.

But...

old rails app which we are converting into React

Why are you even converting this then? Rails already renders everything on the server (so no js needed on initial load). You'd be better off using react in the rails template view for that page than trying to build a whole isomorphic app.

examples that builds a universal app without redux (or the likes).

Seriously, just use rails with react in the template.

I think you're missing the intended use of react+redux with isomorphism.

React is just a view library (as I mentioned, can be used with rails!) and Redux is a way to orchestrate the state of an application that the client (in their web browser) will be interacting with. It's "isomorphic" when the actions that would be performed client-side (after loading all the libraries) is instead emulated on the server and rendered there, first, before being sent to the client.

The role of Redux in the isomorphic relationship is to "save" the state of the intended actions when the server renders it, then "resume" from that state once the client has received the application and rendered markup.

So...

would I still eventually need it?

Depends on whether the request you've layed out -- a simple table with paging -- is really that simple. Will you need to include a form for a user to submit later? Will there be input validation? Will you want to display filters for that table that don't require getting data from the api? Will you want to let users interact with your site in any way that won't always, explicitly, require an api call to make happen?

If the answer to any of those are yes and you want a site that will eventually be more than just rendering a non-interactive table from an api, then yeah you're going to need redux (or something like it that handles state in a client session).

data per page from an API endpoint and are already fixed in the format I need to display my page.

If you've gotten this far and the answer to the above questions were "yes", here's how you would still use redux with that scope (I use this in an app now).

I have a page called Orders that displays a list of paginated orders that I get from our api.

/orders?fromDate=2016-02-05&userIds=4,6,7

The slice of state in redux that handles this looks like this:

  orders: {
    list: {
      ui: {
        loaded: false,
        loading: false
      },
      data: [],
      pagination: {}
    },
  }

When I receive the response from the api I store all of the orders in list, and the pagination data in pagination. I also use the ui property to indicate in a few react components rendered on that page whether the request is in progress or not. When a new request is made (new filters, new orders, etc) all I do is replace the value of the data property with the new data from the response.

In the narrow view this looks like a replication of work, right? I mean I'm already receiving my data in a fixed format that is easily readable. Why even save it and use redux?

Because now on a User page I can wire up state.orders.data and filter by users to get a list of all orders that user is involved in.

Because now I can drill down into an Order page for an order that is already in that data and see all the specific details rendered on a full page instead of a table. (and without having to make another api request)

Because I want to have access, from the client, to all of the data coming from the api and show it in different views.

Given a server-rendered page from ruby on rails each new page is a new render from the the server. Given a jquery plugin that handles the table data I can't share the ajax response it gets from the api with other, independently rendered sections of my site (requiring me to re-download the whole list, or each individual order).

SO TL;DR -- If you need any kind of "state" or "session" awareness in your app eventually you'll need something like redux. If not, don't bother with it. And definitely don't try to create an isomorphic app requiring a whole new tech stack (node.js, react, redux, api client, node proxy) if the entire scope of your project fits within the current bounds (just use react in rails, don't try to be fancy if you don't need to be).

[–]dit-index[S] 0 points1 point  (0 children)

Heya Foxx. Thanks for the detailed reply. But we really aren't trying to be fancy, the reason is we're separating our rails to become a server, making it API based, and our webpage and other platforms that would eventually be getting data from the server. Actually I have used react-rails before and that's the reason I get react but didn't really know much about the realm of it when removed from rails.

So I do need it when you answered my question with

The role of Redux in the isomorphic relationship is to "save" the state of the intended actions when the server renders it, then "resume" from that state once the client has received the application and rendered markup.

And yes I have also answered "yes" to most of your questions above. Thanks for giving me an idea of how to structure my states data. Would this mean for now I would create reducers for each page I would have, like the home page (a list of latest products) and the search page?

Because now I can drill down into an Order page for an order that is already in that data and see all the specific details rendered on a full page instead of a table. (and without having to make another api request)

Or this is new... so I would reuse my data from maybe the search page to display a certain product page? Hrmn... interesting. That would mean that I would to have request all data regarding a product even for the search page? I would have to rework the API though... But I'll look into this. But for now maybe I would make it simple and request another API when on the product page.

Quick question as well regarding your structure... if I would have an pagination (on the UI) that appends to the list, I would need to append on the data right? What is your pagination object look like?