Development

Getting Started

Please refer to the README.md for instructions on installation & local deployment.

Main Technologies

The following are some of the frameworks & libraries used to develop this project. They include:

• NextJS
• React
• Chart.js
• Nivo
• Typescript
• TailwindCSS

Other utility libraries worth mentioning include lodash, luxon & axios

Project Structure

The following is how the project is structured along with a short explanation of what each folder entails to get an idea how to develop within this codebase.

Directory	Description
components	Reusable components used within the application. The 'building block' of the application.
config	Configuration settings for external services or similar. Often used with process.env as a centralized way to read environment variables.
dashboards	Thematic dashboard components. Some of the dashboards are reusable, eg. dashboards with state-level scope (crime, drugs), but majority are single-use.
data-catalogue	Components that are relevant to data catalogue feature.
hooks	Reusable logics in the form of hooks
lib	Utility folder. Contains helper functions, static constants, routes, types & schema(A more nuanced collection of utility helpers)
pages	Refer to NextJS pages
public	Public folder. For hosting locales & static/images
script	Scripting folder. Store scripts for dev purposes only.
styles	CSS folder. All CSS magic goes here.

Naming Convention & Style

To ensure consistency in development, this codebase adopts the following naming conventions. A clean codebase = happy developer.

Type	Convention	Example	Lengths
Component	Pascal case	CovidDashboard	2-3 words
Interface / Type	Pascal case	CovidDashboardProps	2-4 words
Function	Camel case	handleAdd	1-3 words
Variable	Snake case	active_queries	1-2 words
Constants	Upper case	STATES	1-2 words

The length of names should be short whenever possible! But not to the point it becomes hard to make sense. But you might be wondering, won't it be easier to get 'lost'? Not really.

Given how the project is structured, its fairly easy to gain context of 'where' you are developing. With this, we can use short names to piece together what each variable, function represents.

// inflation-snapshot.tsx
const InflationSnapshot: FunctionComponent = ({}) => {
  const handleAdd = (option: OptionType) => {
      return ...
  };
  return <></>
}

In the above snippet, the handleAdd function indicates some sort of adding / concatenating logic. By itself, it is hard to make sense, but pairing it with the component name InflationSnapshot, you can easily make an inference that the function is adding a snapshot. Naturally, the larger the component, the harder it is for you to adhere to this convention and the more verbose your names have to be to provide clarity. If you find yourself reaching to this point, then you might want to consider splitting into multiple components OR abstract the logic into a hook