React structures the application into components instead of technologies. This means that everything that gets rendered on the page has its own file based on its functionality instead of regular HTML, CSS, and JS files. For example, the new report form lives in client/src/pages/reports/New.js
and contains everything needed to render that form (all the CSS, HTML, and JS). It comprises a number of other components, for example the Form
and FormField
components which live in client/src/components/Form.js
and client/src/components/FormField.js
, which likewise contains everything needed to render a form field to the screen. This makes it very easy to figure out where any given element on screen comes from; it's either in client/src/pages
or client/src/components
. Pages are just compositions of components written in HTML syntax, and components can also compose other components for reusability.
- Close any servers you have running (the
./gradlew
ornpm
commands) - Pull down any updates
git pull
- If you see any changes to
src/main/resources/migrations.xml
this means there are updates to the database schema. Run./gradlew dbMigrate
to update your database schema.
- If you are using sqlserver then you need to run
export DB_DRIVER='sqlserver'
to tell gradle to use your sqlserver configuration
- If you see any changes to
insertBaseData.sql
then there are updates to the base data set.
- If you are using sqlite, then run
cat insertBaseData.sql | ./mssql2sqlite.sh | sqlite3 development.db
- If you are using sqlserver, then use your favorite SQL connector to run the insertBaseData.sql file.
- Re launch the backend server with
./gradlew run
- Re launch the frontend server with
./npm run start
Run npm test
to run the linter and tests.
Run npm lint-fix
to automatically fix some kinds of lint errors.
Our tests use selenium to simulate interacting with the app like a user. To do this, we need to connect a browser to the JavaScript tests. We do that via a driver. By having chromedriver
as an npm dependency, we automatically have access to run in Chrome. To use Firefox instead, see geckodriver
.
When writing browser tests, remember that when you take an action, you need to give the browser time to update in response before you start making assertions. Use the driver.wait
method to do this.
If the tests are failing and you don't know why, run them with env var DEBUG_LOG=true
:
$ DEBUG_LOG=true npm test
You can also insert the following into your code to make the browser pause, allowing you to investigate what is currently happening:
await t.context.waitForever()
In rare circumstances, when using Chrome, the tests will hang on the data:,
URL. I don't know why this is. If you re-run the test, you should not see the issue a second time.
The tests are reliant on the data looking pretty similar to what you'd get after a fresh run of insertBaseData.sql
. If the tests crash and do not complete, they could leave the data set in a state which would cause future test runs to fail. To get out of this situation, run insertBaseData.sql
again.
- Create a migration to add it to the database tables
- Edit the bean object to add the field and getter/setters
- Edit the Mapper class to map the field when it comes out of the database
- Edit the Dao class to: a. add it to the list of Columns in the *_FIELDS variable for the class. ( ie PersonDao.PERSON_FIELDS) b. update any SQL to ensure the value gets INSERTed and UPDATEd correctly.
- update the bean tests to include having this property and update the src/test/resources/testJson to include the property.
- Update the resource unit tests to try setting, fetching, and updating the property.
Set the MAP_LAYERS
admin Setting to a JSON object that looks like this:
[
{
"type": "wms",
"url" : "http://mesonet.agron.iastate.edu/cgi-bin/wms/nexrad/n0r.cgi",
"layer": "nexrad-n0r-900913",
"name" : "nexrad"
}
]