The very quick getting started guide
git clone [email protected]:DataSF/open-data-explorer.gitcd open-data-exploreryarn installyarn start
You can see all the libraries in use in package.json. Digging in, you should probably become familiar with the following:
The code structure reflects a redux pattern for managing state in a javascript application.
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 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.
app constants as needed, things like API roots, etc.
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.
this is where all of the specific functions related to external API calls (e.g. Socrata) live.
per the redux approach, reducers change the state based on actions. All state change logic lives in reducers.
styles
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.
the entry point for the application
the routes for the application, the routes point to containers, which then delegate props to their children
We use Zenhub to organize the work. Interested in following along or contributing, make sure to install Zenhub so you can see our boards.
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.
We use Git Flow for branch naming, which follows the format
<type>/<branch name>
The following are the types we use:
- release/: For official releases
- hotfix/: for making fixes off a previous release
- bugfix/: for making fixes for a current bug
- feature/: for adding features to the system
- docs/: for making changes/updates to documentation
Coming soon