Git Product home page Git Product logo

frontend's Introduction

Open Data Visualisation Platform – Frontend

Build, lint, and test Issues License Version Codacy Badge

SINTEF

This repository contains the frontend for the "Open Data Visualisation Platform" developed in collaboration with SINTEF. You may find the backend here. By providing both a dashboard and a Storybook page, users will be able to test different visualisations of their desired datasets. Consult the releases page to get a local, stable copy of the service.

Overview

You can view the current deployment here and our deployed storybooks here.

The frontend is built with React.js, written in TypeScript. We also utilise the Storybook.js library to give an easy to use and intuitive overview of our React components. For deployment we decided to use Netlify. Refer to our wiki for more information regarding our architecture and structure.

Setup

Install the dependencies with:

yarn

Running

Run the application in development mode with:

yarn start

You can view the project at http://localhost:3000.

Launch your local instance of Storybook.js with:

yarn storybook

Then you can view your storybook at http://localhost:6006

Testing

Run the entire test suite with auto-running on file changes with:

yarn test

Installation of NPM package

Our NPM package can be found here. More information about this package can be found in the wiki.

npm i data-visualisation-platform --save

or

yarn add data-visualisation-platform

Example usage

import React from 'react';
import { MetApi, SsbBefolkning, VisualiserProvider } from 'data-visualisation-platform';

const App: React.FC = () => {
    return (
        <VisualiserProvider>
            <Charts />
        </VisualiserProvider>
    );
};

const Charts: React.FC = () => {
    return (
        <div>
            <MetApi.Line width={600} height={200 lat={63} lon={10} />
            <SsbBefolkning.Threshold width={600} height={300} thresholdValue={4} municipalities={['K-3024']} />
        </div>
    );
};

License

Copyright 2021 SINTEF AS

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

frontend's People

Contributors

blauks avatar emilom avatar fredrikaugust avatar fredrikbw avatar kpaubert avatar restyled-commits avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

Forkers

majacq

frontend's Issues

Add the selected visualisation type to the global store

Description

The user should be able to select a visualisation from the ones generated in #84, and this information should be passed to the global store.

Subtasks

  • Allow user to select visualisation
  • Add information to global data store model

Design user interface ✨

Description

Afternoon, @IT2901-SINTEF01/ux-design.
The task is to create a more complete design in Figma that the @IT2901-SINTEF01/frontend team can use as a baseline for their implementation.

Subtasks

  • Create design
  • Add design to design page in wiki

Improve accessibility

A review of the application accessibility can be found here. The review provides an overview of tasks to be done and explains the tasks below in greater detail.

  • Make all custom controls into native HTML elements. If this is not possible, they should have associated labels and ARIA roles.
  • Add labels and/or text alternatives where necessary.
  • Give focus to pop-up alerts when they appear.

Correct GQL Query should be used on dashboard

Description

Right now, the query used on the dashboard is not correct, and this needs to change.

We are gathering an army and preparing to tackle this enormous hindrance.

Sharpen your tools, we're going into war.

Subtasks

  • Create function for determining which type and query should be used based on selections on data chooser pages

Document use of Storybooks

Document how to set up and use Storybooks.

Helpful notes from @FredrikAugust

Useful points:

  • File name format. With this configuration, they have to be (in effect) *.stories.tsx
  • How does a story look? Perhaps provide an example
  • Should you be able to test container components, or only presenational? If you should be able to test container components, it might be useful to provide a wrapper.

Create server error page

Description

In case the server gets hurt we need an error page.

This is low priority.

Go wild 👨🏻‍🎤

Subtasks

  • Create HTML file called 50x.html in /public which will be shown upon error 🤧

Display available visualisations on the visualisation selection page

Description

This is actually a bit more work than illustrated by the title.

The backend metadata field returns a set of visualisations which have a type field, which we can map to different component types (e.g. ThresholdChart, BarChart, &c).

We need to use this information, alongside the information regarding what data source we are working with to retrieve the correct mappingFunction, map the data to the correct format, and inject it into the visualisation. This requires some changes to the way the mapping function is retrieved today.

With this issue (and corresponding PR) you should be able to view the different visualisations available to the data source.

Some considerations

  • The visualisation object from the backend includes some metadata which should be passed to the visualisation (e.g. name, axesName &c)

Subtasks

  • Map visualisation['type'] to chart type
  • Map visualisation['type'] to mapping function (with data source added to the equation)
  • Generate "faked" visualisations on the selection page

Additional information

This issue does not include the actual mapping of real data to the different visualisations. That will be handled in another issue. This does however lay the foundation for that.

Discuss utility vs presentational value

A question mainly for @IT2901-SINTEF01/ux-design, but including @IT2901-SINTEF01/frontend as this will determine their choice of technologies.

When developing dashboards and visualisations it's important to strike a good balance between utility and ✨ aesthetics ✨.

We should probably set some guidelines for the visualisation of data with regards to amount of information, design &c.

Example questions:

  • Can we use smoothing on line charts? This doesn't provide the same amount of granular detail, but looks better
  • Do we want to focus on creating beautiful visualisations that can be used in e.g. marketing or on websites and convey exciting information, or very "statistical" visualisations that target data scientists and researchers? Can we do both?
  • Do we want to spend time implementing animations? They are a huge improvement to the visual impression of the website and give the user a feeling of an interactive experience.
  • Do we want to create a theme between all the components? E.g. use of gradients and rounded corners?

It's a fine line, but I believe it should be at least given some discussion.

  • Include in meeting notes for Wednesday

Create navigation between data selection and visualisations

Description

Using react-router one should be able to navigate between the two pages as specified in the design kindly provided by @IT2901-SINTEF01/ux-design.

Subtasks

  • Create routes for both pages, and setup 404 handler with page
  • Make sure the URL doesn't contain any octothorpes, e.g. localhost:3000/#/path/to/resource. This is a sign of misconfiguration

Related sources

Remove lint CI action

Description

Remove lint action since we have sider.

Subtasks

  • Remove lint action(s)

Storybook invalidates each run due to diff in text in stories

Description

Storybook invalidates all components as they differ in textual content.

PLEASE 🙏🏻

It also makes all builds in master pending as they're not accepted.

Steps to reproduce

  1. Push new build to git repo

Expected behaviour

No diff.

Design for loading and error

Description

The datasets might take some time to load, and may even produce errors. We should have visual components representing these outcomes.

Subtasks

  • Create loading and error designs for datasets, visualisations and other elements which require loading of external resources

Add proxy configuration to avoid CORS restrictions

I got it to work with using proxies on frontend.

Steps to reproduce:

  • Add to package.json:
    "proxy": "http://localhost:5000",
  • Code used for testing
            <button
                onClick={() =>
                    fetch('/graphql', {
                        method: 'POST',
                        headers: { 'Content-Type': 'application/json' },
                        body: `{"operationName":null,"variables":{},"query":"{ forecast { forecastGeometry { coordinates } } } "}`,
                    })
                }
            >
                test
            </button>

Remember that when proxying you need to make a request to the host you're serving the app from. This is done by default when omitting the host in the fetch request, and only including the path.

Originally posted by @FredrikAugust in IT2901-SINTEF01/backend#29 (comment)

Build storybook in pipeline

Might be useful to ensure the storybook builds successfully in Github Actions?

Evaluate whether or not this is performed by the original building. I do, however, believe that it is possible for the storybook to fail building without the main build failing.

Perform simple accessibility review

Description

Even though it's not crucial for our application, we should strive to hit at least the most basic accessibility goals.

The task is to perform a review of the accessibility (or lack thereof) and provide a report to the frontend developers through an issue with subtasks. Might also be helpful to include a PDF or similar.

Subtasks

  • Perform review
  • Create report
  • Create issue
  • Document findings if you see fit

Display visualisation selected by user (and not always thresholdchart) 📊

Description

Make chart type dependent on vis. selected -- i.e. information available in global store after #85.

Conciderations

It might be easier to have all visualisations accept an object (i.e. one argument) and use some clever mapping between input and output.

Subtasks

  • Decide what type of visualisation should be shown
  • Map from raw data to visualisation input

Create dashboard organism

Description

Create a dashboard component which supports multiple child components (visualisations)

Subtasks

  • Create Dashboard organism
  • Create sensible component which supports displaying multiple visualisation (might be useful to take a look at React children and props.children)
  • Decide how you should determine what data should be passed to what component. Do you wish to create very minimal wrapper components (molecules) which simply feed data into the respective visualisations (atoms)? I would recommend creating some examples and evaluating the different approaches. Feel free to send me a message if you want input or have any questions. The decision should be documented in the wiki.
  • Set a standard for how data transformation between raw data source and visualisation component input should be made. Perhaps create a generic type for this which ties into a prop to the visualisation component?

E.g.

const rawMetApiDataToBarChar: (rawData: MetApiData) => BarChartProps['data'] = (rawData) => {
  // ...
}

Related sources

Containerise application

Build the application in a docker image and publish to organisation – just like backend.
An umbrella repo will be created which deploys both of these (with a DB in the future) with a docker-compose "image".

Wireframes in Figma

Description

Create wireframes in Figma. Post link or images here when done.

Subtasks

  • Assign project, milestone, labels and assignees
  • Create figma project and share with team
  • Create wireframe for dashboard

Document project setup and meta-information

README.md

  • Title
  • (Logo and stats if we are feeling cheeky)
  • Two-three sentences about the project
  • How to set up the project
  • How to run the project

LICENSE

  • Add Apache 2 license

Wiki

  • Frontpage with links to subpages
  • Document CI
  • Document architecture
  • Folder structure
  • Testing
  • Code style

Docker doesn't respect modern TypeScript

Description

Our Docker configuration doesn't seem to like non-null assertions, generic components and several other modern TypeScript features. It should support this.

Steps to reproduce

  1. Push a commit to a remote branch (in this repo) using either generic functional components, non-null assertion, or as casting.
  2. Take a look at docker build logs

Example: https://github.com/IT2901-SINTEF01/frontend/pull/72/checks?check_run_id=2148614277#step:8:171

Expected behaviour

No errors.

Details

Deduce from docker builds and Github Actions files.

Create data source selection page

Description

Good morning!

Next up, we need a page where the user can select what data source they wish to use for their visualisation.

In this issue, you only need to implement the page. You do not need to wire it up to a global store for handling selection of data sources.

Subtasks

  • Create data source selection page
  • Retrieve data about available data sources from backend using GraphQL
  • Create buttons (useless ones) for adding data sources

Create type and dummy data which corresponds to MetAPI response

Description

Create a type which corresponds to the response of the MetAPI call. Hopefully, soon you will be able to use the backend to retrieve this data, but this is currently under review.

This type will be the type of the deserialised result from the GraphQL query. If you have any questions about how this works, @blauks should have some knowledge from Ekskom!;)

The dummy data you create could be a JSON file you put in a sensible location, or a JS object in a file. You only have to make sure it's an exact match between the type and the data.

Subtasks

  • Create folder in a logical place for collecting different types
  • Create type
  • Create sample data which is of the newly created type (e.g. const sample: MetApiCompactForecast = { ... };)

Related sources

Set up a mocked provider for use in storybook

Description

To provide some more interesting data to the components in the storybook (as well as avoiding having to store large JSON files everywhere) we can use a mocked provider from apollo.

Subtasks

  • Set up a decorator which provides the mocked provider
  • Mock the api.met.no request

Make this project into a library

Description

This project should be usable as a npm library.

Subtasks

  • Find out how to use this project as a library
  • Create example repository using this library under IT2901-SINTEF01

Create folder structure for future development

Description

Implement an atomic design pattern, and make sure the rest of @IT2901-SINTEF01/frontend understand what this entails.

Some key concepts;

  • Organisms: page structure
  • Molecules: responsible for data retrieval and passing data down to atoms
  • Atoms: entirely self-contained components. Should not require a parent* GraphQL provider. The demo by @emilom is a perfect example of this, where you could enter data in the "storybook configuration field" (hope you understand what I mean). This data should in practise be passed down by a molecule which uses a useQuery to retrieve from the GQL endpoint.

parent* = parent, grandparent, great-grandparent, &c

Subtasks

  • Create folders and use .keep files if you need to push empty folders
  • Document component structure on wiki
  • Explain concept to rest of team

Related sources

Mock should return random valid name for data source

Description

Mocks only return one title for the visualisations, while it should return a sample (read: one) of all available data sources for randomness.

Steps to reproduce

  1. Look at the code and run it and then look at the results

Expected behaviour

Very random (:sparkles: quirky ✨) selection.

Create atom for loading and error

Description

We need custom atoms for loading and errors which can be displayed when fetching data from the backend.

Subtasks

  • Create atom for loading as designed in #32
  • Create atom for error as designed in #32
  • Create atom for cases where GraphQL didn't fetch any data (as designed in #32)
  • Implement atoms in DataWrapper.tsx and Dashboard.tsx

Global store for keeping track of selected visualisations

Description

The frontend needs to keep track of which visualisations are selected, and a global store is a suitable place for that. I believe @emilom found the Apollo state management to be sufficient, so that should be used.

Subtasks

  • Create store and model
  • Test (Unit test) selecting a data source and make sure it's reflected in the store. Do not need UI test

Test adding data visualisations with Cypress

Description

Wow! A complete e2e test!

You should test that adding a data visualisation and navigating between the relevant pages works as expected.

Subtasks

  • Test navigation with 404s as well
  • Test adding visualisation
  • Test deleting visualisation

Create a fitting visualisation for MetAPI Compact

Description

For the MVP of the dashboard, we need a fitting visualisation.

The visualisations should take one data format, which is fitting for that visualisation. So for a bar chart, you may want { x: [1, 2, 3], y: [4, 5, 6] } &c.

Subtasks

  • Create visualisation for MetAPI Compact data
  • Add visualisation to atoms folder (if #26)
  • Add storybook example with visualisation component and the test data created in #27

Related sources

End-to-End testing with Cypress

  • Set up Cypress testing library
  • Set up CI job for testing (@IT2901-SINTEF01/infra)
  • Test launch of website
  • If applicable; extract test artifacts

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.