Review my github repos

・1 min read

So, I'm learning react and now I'm a bit comfortable trying to do projects on my own. I've made a couple of projects in the last few days and I want some help from you guys.If you could take some time to take a look at them and tell me what I'm doing right and wrong and maybe what I should be doing next. I'm fairly new so it's not the best code.
https://github.com/darlingtonp4?tab=repositories

DISCUSS (5)
 
  • Treat arrays or objects in the component state as read-only. This means that when updating state, new instances of the array or object should be created (like with Array#concat or Object#assign) rather than mutating the existing reference. This is to prevent code in other parts of the component from reading corrupted state values. See here in the hackerNews project
  • Store constants outside of state. If these constants can be re-used (like the weatherApp's months array), you can prevent from repeated code by defining them in one place and importing them from a common module/file.
  • Keep implementation details (in this case, the browser event API) encapsulated within components as much as possible. For example, rather than passing a raw form submission event to a parent component, extract the data from the event (since that component has the necessary context) and call a prop function handler with those values. Like fn getWeather(city, country) instead of fn getWeather(formEvent). This makes refactors simpler if a component needs to be added in the hierarchy between the current parent and child.
  • On a JavaScript note, assigning null is preferable to assigning undefined to clear or initialize state data. Without null, undefined values hide whether something was intentionally set to undefined or just not defined to begin with when the component mounted. This distinction makes it easier to follow the flow of data.
  • The standard fetch API defines that the HTTP status code will be stored in the Response#status property (not cod).
  • On general code quality, using constants or configuration properties instead of raw strings lets the transpiler catch spelling mistakes for you. (Like e.target.name === POST instead of e.target.name === "post".
  • In a form change event handler with multiple fields, creating a new function to handle each field eliminates the if/else checks on the event target. An example of this would be like:
  class extends Component {
  ...
  makeChangeHandler(stateKey) {
    // Returns a new function that handles the change event using the given state property.
    return event => this.setState({ [stateKey]: event.target.value });
  }
  ...
  render() {
    return (
      ...
      <input
        name='title'
        onChange={this.makeChangeHandler("valueTitle")}
        value={this.state.valueTitle}
      />
      ...
    )
  }
  ...
  }
 

In terms of what you can do next, I would check out reactpatterns.com and trying to apply them in a project. Especially the container pattern—it makes testing components much easier when the Ajax request is done outside of the rendering component.

 

Also take a look at github.com/adam-golab/react-develo..., it’s a resource I wish I knew about when I first started learning React.
It looks to me like you could benefit the most by studying state management next. Create-react-app and friends have made the tooling knowledge less of an upfront requirement to getting up to speed with React, IMO.

Thanks Matthew I really appreciate the time you took to review my code and your advice. I'll take I look at those resources to continue my journey with react! Thanks for pointing out those mistakes, I know I need to work and practice more to get used to React and stop making those mistakes.Do you think Redux is the right choice for state management? Thanks again Matthew!

By practicing state management, I mean designing and implementing component trees and helper classes in clean ways that properly separate concerns (concerns like page layout, AJAX, animations, event subscription/observation, DOM API encapsulation, testability, etc.).

Redux's FAQ has a good explanation of its tradeoffs: redux.js.org/faq/general

Classic DEV Post from Dec 7 '18

What is a type of "overconfidence" you have observed in developers?

There are certainly a lot of ways developers can be "underconfident" in the for...

Don't miss out on the next important post

Sign up (it's free!)