it2901-sintef01 / frontend Goto Github PK

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

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

Description

Edit sider config.

Steps to reproduce

1. Look at #36

Expected behaviour

Don't lint generated files.

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 🤧

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

• #27

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

Depends on #3

Storybooks

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.

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)

Question

How does Storybook work, what are some best practises, how will we use it, an example?

Related information

Storybook

Description

Implement the actual functionality (updating global state) that adds the data source + visualisation.

Subtasks

• Make the add data source / select visualisation pages functional

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".

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

• Data source: https://api.met.no/weatherapi/locationforecast/2.0/#!/data/get_compact
• might be useful

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.

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

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.

Flow:

• Build
• Check lint
• Run tests (Optional can be added later)

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.

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

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

• Blocked by #53
• react-router-dom

Add a workflow to install packages and build project

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

Description

Remove lint action since we have sider.

Subtasks

• Remove lint action(s)

Description

Build master builds and push to github pages.

Continuous deployment of master should be sufficient as long as we configure the backend path in env vars and ensure CORS settings on backend satisfy the requirements.

Subtasks

• Deploy to GH pages

Related sources

• https://github.com/marketplace/actions/deploy-to-github-pages

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

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

Description

As discussed in the meeting.

Add page for accepting the addition of a new data page.

Subtasks

• Add page
• Handle routing

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

Right now it appears to be using shallow object comparison which means that it will always pass.

Subtasks

• Why we chose it
• Why is it better to use visx than other competitors?
• How we will use it

Related sources

• https://airbnb.io/visx/

With TypeScript, TailWind, Apollo Client and other needed dependencies.

Description

Right now data source is based on the title of the metadata entry that is returned[0]. This is error-prone as some of the titles are quite long and complicated.

It would be better to migrate to a more uniform ID format.

[0] #81

Subtasks

• Review code touched in aforementioned PR to use ID instead of title

Related sources

• Blocked by IT2901-SINTEF01/backend#93

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.

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

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.

Description

A threshold chart will not be the best way to visualise population data in Norway. We should create a new component for line charts which can be added to our library of available visualisation methods.

Subtasks

• Create a line chart in visx

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

Description

It doesn't look good.

😷

Subtasks

• "Trenger bare litt padding"

Description

Make a test (or two) to check the business logic related to adding a new item to the dashboard

Subtasks

• Create test(s)

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

• https://bradfrost.com/blog/post/atomic-web-design/. The pitch above is a slightly simplified version of this, as we probably don't need templates and pages.

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

• Depends on #26
• https://reactjs.org/docs/composition-vs-inheritance.html#containment

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

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

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.

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

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

Description

This should be done once the design is at least partially complete – to the point where colours have been set in stone.

Subtasks

• Update Evergreen config to use your new custom colours.
• Make a decision whether or not you want to support dark mode (confer: @IT2901-SINTEF01/ux-design) and write a sentence about it in Wiki->Design

Related sources

• https://evergreen.segment.com/get-started/theming

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

Examples could be P5js and threejs, try to experiment with them a bit aswell too see what we could do with them.

Post your findings here!

Description

Read title of issue.

Subtasks

• Explain in wiki
• Add description in wiki of what it does
• Add badge?

![Deployment badge](https://img.shields.io/github/deployments/it2901-sintef01/frontend/Production?label=Production%20deployment)

Related sources

• https://vercel.com/it2901-sintef01/frontend