erlanglab / erlangpl-ui Goto Github PK

Version 4 just came out recently so we should bump it because we were using beta release.

When I was creating default tabs for UI I was thinking about /messages view as integration with existing erl_3d. Since we'll replace this view with 2nd and/or 3rd level of /traffic view we should disable /messages view right now until we figure out how to use 3D visualisation within this project.

We should add functionality to show node labels in supervision tree. It will help with tree branches recognition. This option should be opt in.

We had discussion with @arkgil about erlangpl and erlangpl-ui structure, how to manage server/client side code of plugins.

As follow-up to this discussion we have to change project structure to make it pluggable. Right now we have 3 default plugins:

• epl-dashboard - /home route
• vizceral-thingy - /traffic route
• epl-sub-tree - new route

Each plugin should export React component, reducer and socket listeners. Whole part will be connected together within main project to keep data management centralised.

Possible solutions:

• I was thinking about lerna but it's more for multiple packages projects like babel, and it forces to publish to npm. I want to avoid that right now.
• Keep all plugins in separate folders within src (due to CRA imports restricted to src)
• Create separate repo for every plugin. This require babel build for every plugin but, as well as glob copy of all css files. Solution to this could be nwb

Since we are not creating proper plugin system right now, I'm leaning towards second option because it require no setup and just works. Later on, designing proper plugin system, we can think about easy way for creating external plugins in both React and Elm.

/ cc @arkgil

Right now we're using some image and logo, which are not transparent. We have to change it to one image with transparent background.

Right now loader only blinks but when we'll connect to real data we'll have to wait for first set of data to show the graph and loader will be shown for a much longer time than it is right now.

It's very annoying when switching back and forth between tabes you have to wait few seconds to get tree view. We definitely should improve that.

This view should contain some copyright info, change log, contact, webpage, link to documentation, etc.

It's important because it's written in Elm as out example how to integrate Elm within erlangpl. Being simple static view it's still value to have it written in Elm to show how any Elm view can be written.

Not everyone has required formatters installed, so it's good idea to add them as devDependencies to npm and run on pre commit hook.

Follow-up issue to this comment.

Each plugin should export list of routes it want to connect, and set of listeners to that routes. Then main socket part will traverse all possible routes and listeners concatenating them into nice list.
This will make connections and listeners cleaner because there will be only one connection per route and one listener (containing listeners from plugins) per topic within route.

This issue is an umbrella issue for Erlang Performance Lab UI plugin system.

We're working on plugin system which will provide other developers easy way for creating new functionality for Erlang Performance Lab.

Our key part are epl-scripts. This is Node dependency providing dev, build and test functionality for every plugin. It's preconfigured blackbox with all required parts for new EPL plugin development. Because by default epl-scripts are preconfigured we support almost none additional configuration. But there comes eject functionality. You can eject your project which move all epl-scripts config and scripts into your project. This allow you to tweak configs and/or add custom functionality which we don't support. This is one way path. You cannot revert ejection.

Another part are epl-components. This dependency will provide styled component for building new EPL views as well as some helper functions for socket connection, Footer and Menu API, etc.
Both epl-scripts and epl-components will be published to npm.

erlangpl-ui will require some refactoring to allow plugins loading in both development mode as well as production mode. In later phase we're thinking about loading additional plugins at runtime, but this may change in the future.

epl-scripts

• Add Elm support erlanglab/epl-scripts#2
• Make eject work erlanglab/epl-scripts#3
• CSS and static files export/import erlanglab/epl-scripts#4

epl-components

To be defained

erlangpl-ui

• figure out development method
• inject styles and scripts for prebuilt plugins
• register Component, reducer, and navigation for every available plugin

When you have large application and you want specific node there should be option to search for it based on pid. All irrelevant nodes should be grayed out showing only matching node with links.

This is good idea to have such feature because it allows easy text to html rendering.
About page is perfect for such feature because it'll contain a lot text with links, images, code snippets etc.

When going to /traffic in Chrome and Safari with a single node running there is not visual representation of that node (included DevTools console in hopes that would help):

If I mouse around I am able to get the hand icon and click into the nothingness and get into the traffic view for that node.

In Firefox it doesn't get past the loading image and has an error in the console:

I'm not familiar with browser support of WebGL so I'm not which browser was best to check with.

> node --version
v6.9.1
> elm --version
0.18.0

Please let me know if I am missing anything or could provide more information.

Right now elm-webpack-loader is looking for changes in src/elm folder and any nested file is omitted in watch mode. This makes Elm development not very smooth, and since we want to write more code in Elm we have to resolve this issue.

Recent PR elm-community/elm-webpack-loader#104 should resolve this issue. Will update dependency once new version will be published.

@arkgil said he's experimenting with this view. The idea is to have supervisor tree, the similar to Erlang observer.

Idea is to implement it with http://sigmajs.org/ library because it has look we're interested in.

Plugin should export React component, reducer and socket listeners if is listening to any.

Right now WebSockets are very primitive. Converting it to promise based approach allow us sending promise based messages to server.

socket.send('topic', { message })
  .then(response => {})
  .catch(error => {})

We have to put some work into restoring lost connection as well because maybe we're using erlangpl on separate machine within the same network and we lost connection, etc.

I'm creating this issue because since we ejected create-react-app we can tweak our CSS imports a little.

Two options I'm thinking of are:

• CSS modules - allow us to keep CSS restricted to given component which is great
• SASS - variables, less code

I'm leaning towards CSS modules.