Month: Jan 2019

I haven’t done this before where I post about what is currently in my development tool-belt. Within these last couple years of React development from 2016 to now, I’ve grown a lot, and I’ve worked with great tools, coding techniques and different patterns. You may check out this article where I explore patterns for migrating a legacy SPAs to React.

My mission with this blog post is to show you my current development tool-belt for creating a new web application:

• What core technology do I use and why?
• What packages do I use and why?
• How do I structure my code and why?

Starting with the Core Technology
My coding core technology is JavaScript.
Why JavaScript?
From 2005 to 2012 I use to build web applications (monoliths) using ASP.NET. In 2013 I made the switch to start separating my Back-end from my Front-end by using AngularJs for my Front-end. This switch gave me the ability to unit test my Front-end. The Back-end became a simple REST API that could be consumed by other applications as well, example Mobile Apps. It was also far more comfortable to code Web Apps in AngularJS using JavaScript, and I was hooked on JavaScript for everything. It was around this time I also started experimenting with nodejs (However, that’s for another blog post in the future. Back to my current development tool-belt)

So fast-forward to now; JavaScript keeps getting better and better, the community keeps creating amazing open source technologies for us to use. The ECMAScript Wizards keep adding new features and keep making JavaScript great.

My web-app core technology is React.
Why React?
I’ve invested in books, front-end masters courses and many many more hours spent on blogs and tutorials. I’ve also been using it at work since 2017 till now. I know the ins and outs of React quite well, and with React you’ve got React Native as well which allows you to do mobile apps. At the moment React is my default front-end tool, and until something comes along that’s going to dethrone React as React did with Angularjs then I might consider it, but for now, its all React for me.

Okay, great so at this point, I am using JavaScript and React.
When I start a new project, I use create-react-app.
create-react-app is a React boilerplate for more info go to https://github.com/facebook/create-react-app

$ npx create-react-app zulucoda-tool-belt-app --typescript

Why I use create-react-app?
I use it for everything. When I need to create a prototype to verify a package or feature quickly. By default it has all the basics you need:

• Test framework – Jest – https://github.com/facebook/jest
• Webpack is already configured for deployment – https://webpack.js.org/
• Just everything you need to create a new web-app.

Now that I have my core and project created, What packages do I use and why?

I am separating these into production dependencies (packages needed by the web-app to run in production) and development dependencies (excellent packages which make my development workflow superb)

Production Dependencies
Redux for State Management – https://github.com/reduxjs/redux & https://github.com/reduxjs/react-redux
Why Redux?
Once you understand the Redux architecture you, always want to create an application using this architecture. more info, please see how I use redux on migrating a legacy SPA.

$ yarn add redux react-redux

---

Redux-Sagas for Side Effects/Middleware – https://github.com/redux-saga/redux-saga
Why Redux-Sagas?
I use to use Redux-Thunk for Redux side effects/middleware. However, a while back a colleague of mine Mateusz Bosek introduced me to Redux-Sagas, and the Redux-Sagas pattern is terrific. Check out this article where I used sagas for migrating a legacy SPA to React.

$ yarn add redux-saga

---

React-Intl for Internationalising – https://github.com/yahoo/react-intl
Why React-Intl?
Before moving to Dubai, UAE. This package would not be on the list because all applications I worked on in South Africa only supported the English language, therefore, there was no need for React-Intl. However, this was just a lazy design because what if we did want to support an additional language we would have to refactor the entire application. So right now any application I work with has React-Intl by default even if only one language is used, at the start. If I need to add additional language support, the application is ready to support that.

$ yarn add react-intl

---

Material-ui for UI (Layout, Theme and Styling Components) – https://github.com/mui-org/material-ui
Why Material-ui?
There’s a massive community behind this open source project. React components that implement Google’s Material Design.

$ yarn add @material-ui/core

---

Development Dependencies
Because I used create-react-app to set up my React development. I already have the following:

• Jest – for unit testing. I update my package.json file by setting the unit test code coverage.
• Typescript – for type checking (In 2019 you must add types to your code.)

Update package.json

"jest": {
    "coverageThreshold": {
      "global": {
        "branches": 100,
        "functions": 100,
        "lines": 100,
        "statements": 100
      }
   }
}

Other development dependencies that help me with my development workflow:

Enzyme – https://github.com/airbnb/enzyme
why Enzyme?
I use it for unit testing React components (the view). I test things like button clicks, trigger onChange events, etc… I aim to have to have 100% test coverage in my React applications. See this blog post on unit testing in React.

$ yarn add -D enzyme enzyme-adapter-react-16

---

Prettier – for code format. https://github.com/prettier/prettier
Why Prettier?
No one has time to format their code :D, therefore, let prettier format your code for you. Decide your format rules upfront and let prettier do all the work. I configure prettier with husky and lint-staged to automatically format every file I commit. Therefore all code committed to GitHub is formatted automatically by prettier.

$ yarn add -D prettier husky lint-staged

Setup in package.json file

  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "node_modules/.bin/prettier  --config .prettierrc --write",
      "git add"
    ]
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
}

Create .prettierrc file

{
    "singleQuote": true,
    "trailingComma": "all"
}

---

Okay, so now that I covered my core, and my main production and development packages. Next on the list is the coding structure.
With this fantastic React development environment set up with these main packages, and unit test coverage setup. All is useless if the coding structure is not modular or lacks a good structure that can scale.

Folder structure

config folder
This is where I set up my root reducers, sagas, etc.

modules folder
The modules folder is where I create my features for my web-app. Each feature has a components, containers and pages folder. Regarding nesting, before I’ve had a situation where I went crazy with nesting components inside components, this resulted in a complex nesting and over time the structure became difficult to work use. So the rule I use now, is I don’t go past 1 level of nesting. This means in the parent components is on the same level as children components. At first, this seems weird over time, and I got used to it. The same rule applies to containers and pages.

shared folder
In the shared folder, I place all items which are common or used in multiple places. This also where I place the API interface as well. The same nesting rules apply for shared folder structure.

Summary
Currently, this is I what use and its working for me. However, this is not cast in stone; it’s like an evolving style guide. Additionally, the packages and patterns that I am using are working for me right now, once again when I come across a package or patterns which works better or easier, I evaluate it, try it out and then it gets added to my tool-belt.
Repo: https://github.com/zulucoda/zulucoda-tool-belt-app