The search interface for KnowWhereGraph.
The project has two environments that it can be run under:
Before building, the cache must be generated. Handling this task before the actual angular build step ensures that the cache is included in the dist/
folder. You'll need an empty folder src/assets/data
; create it if it doesn't exist (mkdir src/assets/data
).
To generate the cache, call either of the two commands below, depending on which environment you want
npm run cache-prod
or
npm run cache-stage
When building choose between the configurations specified in with the --configuration
flag. The production
flag should be used for production builds and stage
for staging.
ng build --configuration <production/stage/local>
This command builds outputs the build in the dist/
folder.
Building inside a Docker container is also supported for automation and to avoid any system dependencies. See the sections below for each environment.
docker-compose docker-compose.production.yml -f up
docker-compose docker-compose.stage.yml -f up
docker-compose docker-compose.local.yml -f up
There are three types of deployments:
When working on the faceted-search, use the traditional ng serve
. Visit the site locally at http://localhost:4200.
These facets are dynamic: their content is fetched from the graph endpoint and then rendered into a tree. Each type of tree has a different function for populating its children. To debug a broken tree, make sure that the endpoint is available.
The autocomplete suggestions are loaded from a cache and inserted into the DOM. If an autocomplete facet is broken, ensure that the cache file is loading though the network tab and check the console for errors. If it's not being loaded, make sure that the files exist; generate them if they don't (refer to the building section of the Readme) .If the cache is being loaded, ensure that the subroutine responsible for loading it into the DOM is parsing it properly.
Each table is represented by a component. Table populating happens after component construction (when new tabs are visited) and when facets are changed. A number of queries are sent to fetch the data. The results are stored in an array in the table component, which the UI reads from. If the data isn't being shown in the table, there might be a problem with...
The location of each thing (expert, hazard event, place) is returned from a SPARQL query. This same SPARQL query also retrieves the other information about the thing (label, etc). The locations are aggregated and then fired off in an event, to the map component which handles the logic of placing them on the map. If something isn't showing on the map
The UI lets the user know what's happening with their query (running or counting). Each table component interacts with that portion of the UI through event messages. When a query starts, an event is triggered to let the search component know to update the status. Same when the query finishes and counting starts, and when counting finishes with the total number of results. If this status is incorrect it could be from a number of things.
Between releases, the project should go through a testing phase. A few key workflows are given below.
The autocomplete facets should suggest the closest match to what you have typed into the facet. These include
In each case, type the beginning of a value and make sure that the closest match is suggested.
Make sure that the GNIS, Location, Expert, and Hazard Type tree selection facets expand properly. Also make sure that the query results look accurate.
Each result shown in the table is a clickable link that brings you to phhuzz.link. Confirm that, in each table view, the links are correct and bring you to the appropriate page.
Make sure that the table can correctly be navigated through by changing the number of results per page and then by changing the page.
The Faceted Search follows versioning conventions from Semantic Versioning.
Contributions as issues and pull requests are welcome. New features should be made as pull requests into the develop
branch and attached to an issue. The pull request should detail what was done, how it can be tested, and any relevant documentation updates. The project uses prettier for code formatting, with line widths set to 120 characters.
Before creating pull requests, prettify your code changes with prettier.