DEV Community: Codebreather

Coding Best Practices

Codebreather — Mon, 23 Mar 2020 09:10:29 +0000

Code guidelines

Prefer small, simpler functions and components over longer ones. Bigger functions and components can always be decomposed into smaller parts.

Why?

Bigger Functions/components are harder to follow/read. They can also introduce complexities into your type declarations and testing.

Ideally, Functions should hardly be longer than 20 lines. When it starts to get longer than that, start thinking of how you could break down the complexity and abstract more specific logics out into other functions, in line with Single Responsibility of the SOLID principle.

Why?

keeping things more focused can help keep others reading your code engaged.

DRY up your code, however, be mindful of premature abstractions/generalizations. It’s okay to repeat somethings. It can help to save some headaches down the line if you did not make a wide generalization earlier on. Use your discretion to strike a balance.

It is okay not to know every underlying implementation details of each sub-function just the same way we utilize helpers from third party libraries and not worry about their implementation details. We mostly care about what arguments the function takes and what it returns. Typescript and automated testing of your helper function can help to increase confidence. However, when creating abstraction, consider if people would ever have to understand the nitty-gritty of your abstraction to use it well. Otherwise, consider simplifying it

Why?

React Components should hardly be longer than 100 - 200 lines. Rather than having several logics in a component, abstract the logic into normal helper functions or hooks if the logic relies on other hooks.

Prefer at most 5-10 custom properties for your react component. Having more custom properties might be a sign that you need to break down the component into smaller parts and group them into a logical shared folder

Avoid passing props beyond one level. Prop drilling can often make debugging harder and also make it difficult for others to follow your code. When you need to pass props beyond one level, prefer using Context API with hooks. This combined with typescript greatly simplifies things

Be mindful of premature optimizations with React’s memoizing functionalities as React is quite fast. Memoizing introduces complexities into your codebase, hence, you want to be sure that you are reaping the benefits

Use very specific descriptive names for variables, functions, components, and types, even when it seems longer e.g getEntireStudentsSummerData over getData.

Why?

It reduces the mental work for others and yourself to understand your code. It documents your code better and prevents the need for comments oftentimes. Too much commenting of code can also be a bad practice because the code and comment could get out of sync if the implementation changes at some point but the developer forgets to change the comment.

Prefer pure functions whenever possible.

Why?

They are easier to test and lead to fewer bugs.

Prefer arrow functions whenever possible.

Why?

They are easier to type and more predictable(no this complication).

Type your react component as FunctionComponent(FC)

interface ModalProps{
  id: string
}
const Modal:FC<ModalProps> = () => {
  return (
    <div>
    Some text here
    </div>
  )
}

Avoid big reducers as they are just like every other function. Reducers can always be split into sub-reducers.The React ecosystem has moved from HOC/Props towards more functional hooks, hence, we should try to move towards that as they are simpler, easier to type and debug

Avoid reinventing the wheel.

Why?

It saves time and energy

However, avoid overusing of third-party libraries. If it will take just a few lines to implement functionality, it might be better to just implement that yourself rather than downloading an entire library?

Why?

It reduces the work of upgrading dependencies.

It helps with bundle-sizes, especially when the alternative library does not support tree-shaking.

Not having to deal with breaking changes introduced by the third-party library.

Be mindful of using third-party libraries with smaller community/support, except if it’s critical and time-saving.

HOW TO WRITE MAINTAINABLE CODE

Codebreather — Tue, 17 Mar 2020 06:00:26 +0000

Frontend guidelines

Prefer small, simpler functions and components over longer ones. Bigger functions and components can always be decomposed into smaller parts.
Why? Bigger Functions/components are harder to follow/read. They can also introduce complexities into your type declarations and testing.

Ideally, Functions should hardly be longer than 20 lines (humans have short attention spans) and keeping things more focused can help keep others reading your code engaged. When it’s getting longer than that, start thinking of how you could break down the complexity and abstract more specific logics out into other functions, inline with Single Responsibility of the SOLID principle.

Use more specific descriptive names for variables, functions, components and types e.g getEntireStudentsSummerData over getData

Prefer pure functions whenever possible

Avoid big reducers as they are just like every other function. Reducers can always be split into subReducers.
The React ecosystem has moved from HOC/Props towards more functional hooks, hence, we should try to move towards that as they are simpler, easier to type and debug

How to reduce your redux boilerplate by up to 80% - reduxios

Codebreather — Sun, 12 Jan 2020 17:48:21 +0000

`reduxios`- Reduce your redux boilerplate by 80% in 4 simple steps

This library provides utility functions specifically for handling reducers and actions related to data fetching which helps to decrease redux data fetching code by about 80%

Installation

npm install reduxios
# or
yarn add reduxios

Example Usage in 4 simple steps

Generate the helper with the basename for action types

import { reduxios } from "reduxios";

export const booksStoreFetcher = reduxios<Book[]>("FETCH_BOOKS");

Create the Reducer, which will handle various Fetch states. It takes the initial data as an argument

export const booksReducer = booksStoreFetcher.createReducer([]);

Makes the action hook for Fetching your data or calling the API.

import axios from "axios";

export const useFetchBooks = () => {
  return booksStoreFetcher.useResource({
    axiosInstance: axios, // This can also be an axios instance created
    method: "get",
    url: "/books"
  });
};

Use the action hook and state in your component. No need to dispatch the action.

const BooksList: FC = () => {
  const fetchBooks = useFetchBooks();
  const { data, fetchState, axiosErrorResponse } = useSelector(
    (state: RootState) => state.books
  );

  useEffect(() => {
    fetchBooks();
  }, []);

  return (
    <div>
      <h1>My Book List</h1>
      <ul>
        {data.map(book => (
          <Book key={book.id} book={book} />
        ))}
      </ul>
    </div>
  );
};

That's it! No need to manually write out action creators, type declarations, reducers and data fetching attempt/success/failure/reset handling. You get everything out of the box!

Want More Detailed Explanation?

Check the Github Repository here

DEV Community: Codebreather

Coding Best Practices

HOW TO WRITE MAINTAINABLE CODE

How to reduce your redux boilerplate by up to 80% - reduxios

reduxios- Reduce your redux boilerplate by 80% in 4 simple steps

Installation

Example Usage in 4 simple steps

Want More Detailed Explanation?

`reduxios`- Reduce your redux boilerplate by 80% in 4 simple steps