I'm new to React Native and new ish to starting my own projects from scratch. What are some best practices to document what each prop type does and which prop types are required for custom components I'm creating?
It's fresh-in-mind when I've build the component and know how the props behave that day. Yes, it might be able to be observed by parsing through the code where the function components were defined, but I'd like to make it as easy as possible to easily access and know at the time of calling and using the Component.
If a future developer or myself in 1 week+ comes back and wants to use these components, the experience of seeing what props are possible and what they do should be accessible.
Any ideas of how you like to navigate documentation best practices like this? Love improving the developer experience :) Thanks!
I am new to react and Redux and utilize a react project on GitHub: overcode/rovercode-ui to learn react and Redux. I have some questions about it.
For each component in fold component, I cannot find why the component has so many props. For example, for Workspace component, at the end of file \component\Workspace, it checks the props of Workspace component. I wonder where these props come from (namely where these props are defined), e.g., the code props.
Action createProgram defined in file \actions\code.js use an asynchronous POST method to create an id for newly created program. However, in the sub-reducer \reducers\code.js, when action.type equals to CREATE_PROGRAM_FULFILLED, id will be extracted from action.payload to save into global state. So, how the id is saved into the global state and action of type CREATE_PROGRAM_FULFILLED is dispatched?
Can anyone help me analze this project? Thanks a lot :)
Hello and welcome to React - Redux universe. I am sure you will love it but regardless of your background or experience level, you have to make your peace with the fact that there is a learning curve and when you are especially new to thinking in terms of components, developing a different mindset takes time. Don't worry, we all been there and it will past. Just give yourself some time.
I am afraid, even if we spend some time together to analyze this project, I don't think that it would make your life easier in terms or learning React or Redux. Analyzing this project is more like helping a beginner foreign language learner to translate a story. It might help you to understand the story, but at the end you won't probably be able to write a new story in the language you are trying to learn.
That said, I'll try to briefly provide answers to your questions and try to point out why analyzing this specific project will not be as helpful as you would expect
1) In order to comprehend where all these props come from, you need to recognize the following pattern that is
connect(mapStateToProps, mapDispatchToProps)(Workspace))
so basically, thanks to connectfunction, you can connect your component directly to the redux store (you name it as global state)
For instance, let's take a look at the following snipped from the file https://github.com/rovercode/rovercode-ui/blob/alpha/src/components/Workspace.js#L36
const mapDispatchToProps = (dispatch, { cookies }) => ({
updateJsCode: jsCode => dispatch(actionUpdateJsCode(jsCode)),
Basically, thanks to mapDispatchToProps we return an object. And since we use mapDispatchToProps as a parameter of connect function, connect function takes the properties of the returned object and passes them to component as props.
Thanks to that, in the following line https://github.com/rovercode/rovercode-ui/blob/alpha/src/components/Workspace.js#L293 we could manage to extract updateJsCode from the props
So, good news and bad news. In order to explain this to you, I need to spend some time to build a fundamental understanding of what is props, what is higher order components, what is redux, what is actions etc. etc. Once you learn the fundamentals first, it is easier to connect the dots.
2) So in order to answer this question, I need to go through the codebase to understand the architecture of the project. The important thing to be aware of is that, even though there are some certain best practices, every project has its own data structure and architecture. It is up to the creator of the projects to make a decision in terms of component architecture, data structure etc. etc. When you are new and try to understand the technology by checking existing projects, you might end up confusing yourself big time and treating the architecture of those project as source of truths.
My humble suggestion to you is, first things first, try to focus on React without Redux. Because most of the time, you might not even need a state management depending on the scope of the project (again a decision needs to be made by the team etc.)
The things that you might want to learn with React are
1) Parent-child-sibling component relationships
2) React Hook api (relatively new, but usage is increasing dramatically so as a new learner you should definitely take a look)
3) If you want to understand some "old" project and tutorials you might also want to learn about life cycle methods
4) What is presentational component vs container component
5) Higher order components
Once you are comfortable with the fundamental of React, you can then continue with Redux. I bet things will be way more easier
If you need more suggestions, send me a message so I can try to provide you some resources
Thanks for your answers. After reading your reply and learning related conceptsI, still have a question. You explain that connect(mapStateToProps, mapDispatchToProps)(Workspace)) connects component directly to the redux store and use the example to illustrate that mapDispatchToProps connects actions to component. So my understanding is mapStateToProps connects state of redux store to component. e.g., code code property of this.props comes from the state of redux store, returned by reducer. Is it right?
I am struggling with myself about what needs to be a component?
For example:
I have a page where everything within is relevant only to itself.
I have a text input on every form control; Do I need to wrap this in a component? But every place will need a different kind of validation and other stuff related only to it, so why do this?
Usually, when it comes to forms, only the style is the same so why we need to wrap this in a component? We can just share the style with CSS.
The tl;dr; is that a component is a reusable, encapsulated piece. It's similar to Brad Frost's Atomic Design. This is not rocket science, different people may split their apps into different components.
That said, there are more than enough tutorials/articles that will help you to understand when to create a component. To get you started:
https://medium.com/#rajaraodv/step-by-step-guide-to-building-react-redux-apps-using-mocks-48ca0f47f9a
https://medium.com/#dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
Reasons where you will want to split into a component:
Reuse code across multiple files/parts of your code.
Encapsulate the complexity of certain code so that fellow developers can use it without needing to understand its implementation details; just need to look at props.
You need to do stuff within specific lifecycle hooks, e.g. do certain stuff in componentDidUpdate when the component updates.
You want to optimize the rendering and have to implement shouldComponentUpdate for certain parts of your code.
In the getting started video of Redux we see that the Footer (a dumb component) uses Filterlink (a container).
But when I read this article, it seems, but not very clearly, that only containers should use/render containers.
For me, if Footer uses Filterlink (which is tied to Redux) I can't reuse it on other projects which don't use Redux. But maybe it is an exception? Maybe hard coding dumb component for use only on one project is ok?
Am I missing something?
The article was somewhat out of date with how I think about it today. I just updated it so you can read it again with the fresh perspective. I’ve come to the opinion that it’s totally fine to use container components inside presentational components. The reason for this is simple: you want to be able to turn a presentational component into a container component at any time it needs too much information, and it would be a bummer if you had to convert all call sites when you do that. Therefore whether a component is presentational or a container is its implementation detail, and any components, whether presentational or containers, can use it just fine.
I was wondering something about the reverse data flow in a React app.
Considering this question: data flow in react application and this article http://facebook.github.io/react/docs/thinking-in-react.html
We can see that the "normal" way to communicate from child to parent component is using callback passing through this.props.myCallback. (the StackOverflow article is a good example)
My questions are:
I understand the concept but what if we have deeper components? We would have to pass this callback to every component between the top parent component who hold the state and the actual triggering component. And if there is 3 to 4 components between them, I would have to pass the callback using this.props in each component.
Why not using an Event Emitter? I could send an event from the deep child component and then listen to this event in my top state parent component. This way we could avoid all the code between these two.
Please tell me what are your thoughts about this!
I learnt the hard way that it is a good practice to keep as much logic as possible in the highest level in the hierarchy of your components. Dan Abramov well expressed this idea in the article Smart and Dumb Components, where Smart Components are those that hold the logic, whereas Dumb Components are just meant to display.
So yes, the callback mechanism works well when you simply want to update the father's state, or you want the father to do an action whose logic you do not want to belong to the child.
When you have anything slightly more complicated than this I would suggest you go with a Flux-ish architecture of your taste. Flux indeed uses node's EventEmitter to communicate with the components.