daml/navigator/frontend
Andreas Herrmann c7038f128e Fix Bazel warnings (#3414)
* No longer depend on "@bazel_tools//tools/jdk:jar"

To avoid the following warnings
```
WARNING: /home/aj/.cache/bazel/_bazel_aj/c1e06e2358666d118d0ae50e2d32c25d/external/bazel_tools/tools/jdk/BUILD:124:1: in alias rule @bazel_tools//tools/jdk🫙 target '@bazel_tools//tools/jdk:jar' depends on deprecated target '@local_jdk//:jar': Don't depend on targets in the JDK workspace; use @bazel_tools//tools/jdk:current_java_runtime instead (see https://github.com/bazelbuild/bazel/issues/5594)
```

* Targets and files should not share names

To avoid the warning
```
WARNING: /home/aj/tweag.io/da/da-master/compiler/damlc/tests/BUILD.bazel:316:1: target 'simple-dalf.dalf' is both a rule and a file; please choose another name for the rule
```
2019-11-11 15:41:34 +00:00
..
src Remove git-revision from dependency graph (#3365) 2019-11-07 13:29:31 +00:00
.editorconfig open-sourcing daml 2019-04-04 09:33:38 +01:00
.gitignore open-sourcing daml 2019-04-04 09:33:38 +01:00
.modernizrrc open-sourcing daml 2019-04-04 09:33:38 +01:00
apollo.config.js update copyright notices (#2499) 2019-08-13 17:23:03 +01:00
BUILD.bazel Fix Bazel warnings (#3414) 2019-11-11 15:41:34 +00:00
declarations.d.ts update copyright notices (#2499) 2019-08-13 17:23:03 +01:00
karma.conf.js update copyright notices (#2499) 2019-08-13 17:23:03 +01:00
LICENSE open-sourcing daml 2019-04-04 09:33:38 +01:00
Makefile Expose signatories and observers throughout the platform (#1814) 2019-06-26 14:02:59 +00:00
package.json Bump lodash from 4.17.11 to 4.17.13 in /navigator/frontend (#2101) 2019-07-19 16:39:26 +00:00
README.md refresh navigator dependencies (#1621) 2019-06-13 14:19:38 +02:00
tsconfig.json open-sourcing daml 2019-04-04 09:33:38 +01:00
tslint.json open-sourcing daml 2019-04-04 09:33:38 +01:00
webpack.config.js update copyright notices (#2499) 2019-08-13 17:23:03 +01:00
webpack.ui-core.js update copyright notices (#2499) 2019-08-13 17:23:03 +01:00
yarn.lock Bump yarn from 1.13.0 to 1.17.3 in /navigator/frontend (#2346) 2019-08-01 14:11:53 +01:00

Navigator Frontend

The Navigator frontend is based on the ui-core library.

Developing Navigator Frontend

To build the bundled frontend files, use Bazel:

bazel build //navigator/frontend:frontend.jar

To test the frontend during development, start the backend at port 4000 (defined in webpack.config.js), run the following command, and open a web browser at the address indicated in the command output:

make start

This will start an interactive build using webpack-dev-server. Every time you save a file, the frontend assets will be rebuilt, and a push notification will be sent to the browser, prompting it to reload the page.

See the ui-core README for information about the design of some of the core components of Navigator.

Configurable table views

Configurable table views are a rapid prototyping feature, where developers can write a script that returns a list of custom table views for a given user.

Architecture

  • The configsource applet is responsible for loading the config file.
    • The config file source is loaded from the backend /api/config endpoint.
    • The config file source is stored in the state of the applet.
  • The config file is parsed and evaluated in the app UI component.
    • The evaluated config is stored in the component state, and only re-evaluated if either the current user or the config file source has changed.
    • The evaluated config is passed as a property to child components.
  • The customview applet implements the rendering of custom views.
    • This applet forwards all functionality to either the Contracts, Templates, or TemplateContracts applets.
    • The route for custom views only contains its ID. Therefore, the state of the applet initially only holds the ID of the custom view.
    • When the applet UI component is rendered for the first time, it initializes the state of the child applet (it now has access to the evaluated config, passed as props from the app UI component).
  • Config file parsing and loading is implemented in the config module.
    • The config file is first preprocessed using Babel (to support JSX tags and ES6 code).
    • Import statements are implemented using a custom require function, that only provides modules already bundled with the Navigator.
    • The parsed config file is checked for its version.
    • There is generally little run time validation.