Developer tips and tricks

Owned by Lite Farm
Last updated: Aug 30, 2022
2 min read

Useful Tools

Tool name

Link

Useful for

Tool name

Link

Useful for

Webstorm

WebStorm: The JavaScript and TypeScript IDE, by JetBrains

A good IDE with lots of smart coding features, it is also free for students to use.

Insomnia

The Collaborative API Development Platform

Great for testing API endpoints as you are developing them. You can get the auth token for a user from the network tab in chrome for an authenticated user of yours. You then just need to add the farm_id as a header.

React Developer Tools for Chrome

https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=en

You can look in the “Components” tab of your dev tools when you have this extension, allowing you to quickly find the name of the component you need to look at for your ticket (this is especially helpful when you are just getting started!). From there you can use your IDE to search for the component.

Redux DevTools for Chrome

https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd?hl=en

You can go to “Redux” tab of your dev tools on Chrome and see redux actions state changes. It can show you what data is currently stored in each redux reducer. Great for debugging when working with redux store.

Patterns for Managing Source Code Branches - Martin Fowler

Patterns for Managing Source Code Branches

Guidance for how to handle branching with Git.

Useful development tricks

  1. If you are using the location.state object for contextual navigation, make sure you always provide default values in case the keys are null or undefined to avoid bugs.

  2. Always use req.user.user_id instead of req.headers.user_id in the API.

  3. If you create a database transaction in an API route, make sure that in every path the code takes the transaction is either rolled back or committed.

Miscellaneous advice

  1. If you are doing either the frontend or backend work for a fullstack story, communicate early and frequently with the developer(s) who are working on the other part of the story.

  2. If you have a PR that’s been open for a couple of days with no reviews, notify the team and get it reviewed to help the QA review your work throughout the sprint rather than at the end of the sprint.

  3. If you find you have to do a lot of repetitive work for your ticket (e.g. lots of data entry, setting up a new farm a certain way every time you want to test your code, unclaiming sensors with a third party API every time you want to test your code), create a script to help that process along and share it both in the comments on your PR, with @Mwayanjana Bolokonya (Unlicensed), and potentially on sprint-team if it’s likely to see re-use

  4. Currently we do not have a consistent way of handling CSS styling. It’s recommended to stick to one type of styling (scss style sheet, makeStyles, etc) across the application. It’s not feasible to refactor all of the current code, but:

    1. Moving forward stick to one type of CSS styling per component (ideally one throughout the app, but the best approach for styling in this app is up for discussion).

    2. If legacy styles for a component are working as expected, leave them as they are.

    3. Otherwise, refactor them such that all styles for the component are in one place.

  5. Avoid in-line CSS styles.

    1. There are many limitations to in-line styles (ex. you can’t access the hover state of an element)

    2. It can cause specificity issues if you want to override those styles later on.

    3. It makes it hard to find all the styles for a particular component.