Logic behind components (multiple states, store,...???) / Page Assembly

[mar-bi]

Guys, I guess we are at the point where we need to discuss the overall strategy for:

• handling state of components (some of them are forms, buttons, inputs,...)
  They need to handle events, control inputs, request data.

For now I have 2 options: multiple states or redux.

• pages / how we will assemble them

1. enclose everything in components. Page is going to be tidy:

import React from 'react'
import Hero from '../layouts/components/Hero'
import JobsContainer from '../layouts/components/JobsContainer'

const JobsPage = () => (
  <div>
    <Hero type="jobs" />
    <JobsContainer />
  </div>
)

export default JobsPage

2. build on the page
3. mix of 1 and 2 (according to the situation)

This is the discussion, please comment. 💬

[spences10]

I vote redux

[mar-bi]

I'm for Redux too. 👍
However, I haven't try it out of the tutorial apps.
☺😆

[spences10]

Nope, me neither 🙃

https://egghead.io/courses/getting-started-with-redux

I've part watched this 👆

[mar-bi]

I built Reduxstagram with Wes Bos's course: Learn Redux on Youtube. 👷‍♂️

[spences10]

Ha yes me too, that was a great course, I couldn't use it for a demo for some reason on now though

[mar-bi]

@miljan-fsd suggested a very interesting article about alternatives to Redux.

After reading it + some additional reading i tend to use mobx.

My reasons: I don't have much experience with Redux, especially with managing async requests (third-party API, DB). As I know async requests require extra packages like redux-saga.

Instead I can get all this (i hope) with mobx.

On the other hand, If we have in our team a Redux professional or volunteer who takes the task of managing the app state with Redux, I agree 🙃

[mar-bi]

Guys, are there any ideas about handling state? Redux, mobX?

Let me describe our current state with the app state:

• now it lives in 2 container components: JobsContainer and CoursesContainer (I followed react best practices and kept the state in a container component). They have a very similar structure.
• the states of these components has 2 patterns of usage:
  1. static, no mutations, for rendering of children
  2. dynamic, with mutations (search and filter queries, fetching data from API (fakeAPI for now))

As I understand now, the static piece of state we can move to gatsby-config.js adding to siteMetadata and then query from the layout (not components!!!) or pages with graphQl.

The dynamic piece of state we can move to a store. The question now is what is better to choose Redux, mobX, something else, or keep in the containers. 🤔

Please share with me your opinions. ❓ 🆘
Thank you.

[spences10]

Apollo

[spences10]

Apparently, Apollo will be the much more user-friendly one to use, if Wes and Scott are anything to go by 😄

https://syntax.fm/show/027/graphql-here-is-what-you-need-to-know

[mar-bi]

Definitely, we are going with Apollo 💯
We highly appreciate the opinions of Wes and Scott. 🥇 🙃

[spences10]

Yeah, I love the way those guys explain things

Ok, so we're agreed on Apollo, we need to educate ourselves on it now, I guess 😁

I'm currently looking at how Gatsby does data then I'll go onto Apollo, I guess

[mar-bi]

continues in #224

[mar-bi]

app state is managed by apollo-link-state (instead of Redux`)
closed by #132