Nodejs, Express, React, Leaflet, Lodash, jQuery, Browserify, Gulp
This is the NCE Prod branch meaning that changes made for existing production hardware happen here.
On some popular Linux distributions, the default repos include a package named "yarn" that conflicts with the nodejs "yarn" package that is required here. cmdtest is the wrong package.
See: https://yarnpkg.com/en/docs/install#debian-stable
To get / update node package dependencies:
$ yarn
1st build / update source changes
$ gulp
$ yarn start
In your favorite browser, localhost:3000
command: gulp
task: default
command: gulp libs
task: libs
command: gulp mapper
task: mapper
command: gulp buildLess
task: buildLess
The /util directory contains various ruby and shell scripts maintaining and releasing the code.
The ordering and readable labels for Darwin Core fields are maintained in a Google Docs spreadsheet. If this spreadsheet is updated the code for the dwc field dictionary needs to be updated for the client-side js.
The data quality flag names and descriptions are maintained in a Google Docs spreadsheet.
The iDigBio portal is mostly a front-side rendered app that takes advantage of Reacts' server-side rendering to allow proper search engine crawling of content pages like Record, MediaRecord and Recordset.
-There is a template in the /app/views directory for each type of page:
Each page has a corresponding JavaScript file in the /public/client/js directory.
All the client side JS is compiled into two files /public/js/client.js -> src file is /public/client/js/main.js . /public/js/libs.js -> src file is /public/client/libs.js
All pages except Home and Tutorial have corresponding React components in /public/client/js/react/src.
React components like record, media, recordset avoid using libraries like jQuery which do not work on the server side so they can be properly prerendered by the server. As such any jQuery tools used (which are only necessary for interactivity) are initialized in the their top level modules in the /public/client/js directory after the React component has rendered in the browser. Also, these page work by requesting the API data on the server and rendering the React component to the page before its sent to the browser. The data is also rendered to the head of these pages so that the browser will do its own React component rendering once the page has loaded.
(specimen) record pages are discovered by Google through the '/list' endpoint. This is a special endpoint not intended for public display so there are no links in the portal to it. /list pages contain links to all record objects in the iDigBio API.
Each page has a corresponding LESS file in the /public/client/less directory. All LESS files are compiled to individual CSS files in /public/css. Each page view template contains a link to its CSS file. The CSS IS NOT compiled into one large client file like the JS code is for the entire portal.
Each one of the corresponding page LESS files will include one or more sub files for reusable display components.
The Search page React component is split in various subcomponent React files kept in /public/client/js/react/src/search/ directory that are loaded in the main React search.js file.
Any changes to the search state are communicated through the searchChange function in the search.js parent component. The searchChange function is passed to all subcomponents as a property if that subcomponent has to communicate changes to the search. This changing of search state allows the page be reactive to all input changes on the search page since changing the search state triggers a render in React.
See the Search.js statics.defaultSearch for an example of what a search state structure looks like.
History is maintained by the searchHistory object using the localStorage API through the client/js/libs/history.js file. The searchChange function pushes changes to history through this object.
Results view tab and the advanced search features tab are kept track of in localStorage API and are maintained through the viewChange function in the search.js page component.
The specimen map used in the portal search page is available freely for public use as a stand-alone map module in JavaScript.
Embedding the specimen map in a website is easy. The following is an example HTML code for simply adding the map to a web page.
The following code assumes you know basic HTML structure and how to use the JavaScript library jQuery. In this example the map is initialized with the element ID of an HTML DIV tag that will contain the map. The map is then queried for all specimens (that have a geopoint) with genus "carex" using the same query format as designed for the iDigBio Search API Query Format.
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<meta content="width=device-width,initial-scale=1.0" name="viewport">
<title>idb map test</title>
<link href="https://github.com/iDigBio/idb-portal/blob/master//www.idigbio.org/portal/css/idbmap.css" rel="stylesheet" type="text/css">
<script src="https://github.com/iDigBio/idb-portal/raw/master//code.jquery.com/jquery-2.1.3.min.js"></script>
<script src="https://github.com/iDigBio/idb-portal/raw/master//www.idigbio.org/portal/js/idbmap.js"></script>
<style>
#map{
width:700px;
height:500px;
position:absolute;
}
</style>
<script>
$(document).ready(function(){
var map = new IDBMap('map');
map.query({"genus":"carex"})
})
</script>
</head>
<body>
<div id="map"></div>
</body>
</html>
The example above sets the map with same options the Portal Search page uses. The following is a list of other options that allow greater control of the map in the context of more complicated web user interactivity.
The following example shows how to initialize the map with alternate options like do not display bounding draw control features or the image generation button and queryChange function for communicating query changes to outer contexts.
$(function(){
var map = new IDBMap('map',{imageButton: false, drawControl: false, queryChange: function(query){
//do something cool with the query in your web page app then update the map
map.query(query);
});
});
map.query({"specificepithet":"concolor", "genus":"puma"})