DataSF / open-data-explorer

To promote exploration and use of open data - currently in beta
http://edge.explore.datasf.org
MIT License
13 stars 2 forks source link
exploratory-data-analysis opendata transparency

open-data-explorer

The very quick getting started guide

  1. git clone git@github.com:DataSF/open-data-explorer.git
  2. cd open-data-explorer
  3. yarn install
  4. yarn start

Libraries

You can see all the libraries in use in package.json. Digging in, you should probably become familiar with the following:

Code Structure

The code structure reflects a redux pattern for managing state in a javascript application.

actions

Actions are payloads of information that send data from your application to your store. They are the only source of information for the store. You send them to the store using store.dispatch()

components

components are similar to views in that they define the rendering of the app. These components are tied to root containers, which define the application logic.

constants

app constants as needed, things like API roots, etc.

containers

containers are a special kind of component. Some people call these smart components, skinny components, controller components. Whatever you call them, they basically define the application logic and pass actions and state down to the components.

middleware

this is where all of the specific functions related to external API calls (e.g. Socrata) live.

reducers

per the redux approach, reducers change the state based on actions. All state change logic lives in reducers.

scss

styles

store

the store holds the whole state tree of the application. A store is not a class; it's just an object with a few methods on it.

app.jsx

the entry point for the application

routes.jsx

the routes for the application, the routes point to containers, which then delegate props to their children

Contributing

Zenhub

We use Zenhub to organize the work. Interested in following along or contributing, make sure to install Zenhub so you can see our boards.

Issue management

We've adopted a similar standardization of labels as described here to make issues simpler to reason about:

https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues/

In addition we kept the help wanted label to indicate good places for others to dig in. There's also an Epic label which is generated by Zenhub to define Epics. Learn what Epics are on the Zenhub blog.

Branch naming format

We use Git Flow for branch naming, which follows the format

<type>/<branch name>

The following are the types we use:

Tests

Coming soon