Skip to content

Commit

Permalink
Merge branch 'develop' into orchid_javadoc
Browse files Browse the repository at this point in the history
  • Loading branch information
aorumbayev committed Jul 13, 2019
2 parents f33b182 + 955a1d4 commit 4b07ea1
Show file tree
Hide file tree
Showing 10 changed files with 584 additions and 502 deletions.
4 changes: 2 additions & 2 deletions .travis.yml
Expand Up @@ -70,8 +70,8 @@ jobs:
- yarn install --frozen-lockfile --check-files --network-concurrency 1
- yarn run eslint
- yarn run build
# - yarn run docz:build
# - netlify deploy -s $NETLIFY_FRONTEND_ID --auth $NETLIFY_ACCESS_TOKEN -p --dir ./docs
- yarn run docz:build
- netlify deploy -s $NETLIFY_FRONTEND_ID --auth $NETLIFY_ACCESS_TOKEN -p --dir ./docs

- name: "Backend"
language: java
Expand Down
39 changes: 39 additions & 0 deletions src/frontend/src/components/Header/Header.mdx
@@ -0,0 +1,39 @@
---
name: Header
menu: Components
---

import { Playground, Props } from 'docz';
import { Header } from './HeaderContainer';

# Header

Headers are a set of simple components based on the navigation [AppBar](https://material-ui.com/components/app-bar/) inside LinkedPipes Applications frontend.

# Structure

The `HeaderComponent.jsx` and `HeaderContainer.jsx` are used for an example in this documentation. The actual header components are inside the folders corresponding to appropriate webpages.

```.md
β”œβ”€β”€ HeaderComponent.jsx # Stateless react component, responsible for ui
β”œβ”€β”€ HeaderContainer.jsx # React PureComponent, responsible for states
β”œβ”€β”€ AboutHeader/ # Folder containing a header components specific to About page
β”œβ”€β”€ ApplicationHeader/ # Folder containing a header components specific to ApplicationHeader page
β”œβ”€β”€ ApplicationsBrowserHeader/ # Folder containing a header components specific to ApplicationsBrowserHeader page
β”œβ”€β”€ DashboardHeader/ # Folder containing a header components specific to DashboardHeader page
β”œβ”€β”€ DiscoverHeader/ # Folder containing a header components specific to DiscoverHeader page
β”œβ”€β”€ SettingsHeader/ # Folder containing a header components specific to SettingsHeader page
└── index.js
```

## Properties

This is a reference example of a navigation component that you will see on every single webpage of the platform. The titles of the sections, and functionality of the tabs will differ.

<Props of={Header} />

## Example

<Playground>
<Header />
</Playground>
Expand Up @@ -46,6 +46,9 @@ const SolidProviderComponent = ({
</MenuItem>
{/* <MenuItem value={'Inrupt'}>Inrupt</MenuItem> */}
<MenuItem value={'LinkedPipes PODs'}>LinkedPipes PODs</MenuItem>
<MenuItem disabled value={''}>
Stay tuned for more supported providers...
</MenuItem>
</Select>
</FormControl>
);
Expand Down
11 changes: 7 additions & 4 deletions src/frontend/src/containers/HomePage/HomeController.jsx
Expand Up @@ -10,8 +10,11 @@ import { toast } from 'react-toastify';
import LoadingOverlay from 'react-loading-overlay';
import { userActions } from '@ducks/userDuck';
import { ApplicationMetadata } from '@storage/models';
import { DiscoveriesCollection, PipelinesCollection } from './children';
import QuickStartComponent from './QuickStart/QuickStartComponent';
import {
DiscoveriesCollection,
PipelinesCollection,
QuickStart
} from './children';
import {
Log,
SocketContext,
Expand Down Expand Up @@ -397,7 +400,7 @@ class HomeController extends PureComponent<Props, State> {

switch (tabIndex) {
case 0:
return <QuickStartComponent onHandleSampleClick={handleSampleClick} />;
return <QuickStart onHandleSampleClick={handleSampleClick} />;
case 1:
return (
<DiscoveriesCollection
Expand All @@ -419,7 +422,7 @@ class HomeController extends PureComponent<Props, State> {
/>
);
default:
return <QuickStartComponent onHandleSampleClick={handleSampleClick} />;
return <QuickStart onHandleSampleClick={handleSampleClick} />;
}
};

Expand Down
18 changes: 13 additions & 5 deletions src/frontend/src/containers/HomePage/HomePage.mdx
Expand Up @@ -5,6 +5,7 @@ menu: Containers

import { Playground, Props } from 'docz';
import { HomePage } from './HomeController';
import { QuickStart } from './children';

# HomePage

Expand All @@ -25,20 +26,27 @@ HomePage is a container representing a `HomePage` webpage.
β”œβ”€β”€ HomeController.jsx # React PureComponent, responsible for both UI and states
β”œβ”€β”€ HomePage.mdx # Documentation markdown that you are currently looking at
β”œβ”€β”€ children/ # Children components used within 'HomeComponent.jsx'
β”œβ”€β”€ QuickStartComponent.jsx # Children component responsible for displaying the demo templates
β”œβ”€β”€ PipelinesTableComponent.jsx # Children component responsible for components of Pipeline executions
β”œβ”€β”€ DiscoveriesTableContainer.jsx # Children component responsible for states of Discoveries sessions
β”œβ”€β”€ DiscoveriesTableComponent.jsx # Children component responsible for components of Discoveries sessions
└── index.js
└── index.js
```

## Properties
## QuickStart

### Component
### Properties

<Props of={HomePage} />
#### Component

## Example
<Props of={QuickStart} />

### Example

Example demonstrates the combination of PureComponent responsible for states and stateless component
responsible for UI working together in an isolated Playground.

<Playground>
<HomePage location={{ pathname: '/' }} onHandleSampleClick={() => {}} />
<QuickStart displayName={''} onHandleSampleClick={() => {}} />
</Playground>
3 changes: 0 additions & 3 deletions src/frontend/src/containers/HomePage/QuickStart/index.js

This file was deleted.

Expand Up @@ -52,7 +52,7 @@ type Props = {
onHandleSampleClick: Function
};

export default function QuickStartComponent({ onHandleSampleClick }: Props) {
function QuickStartComponent({ onHandleSampleClick }: Props) {
const classes = useStyles();
const [executeScroll, scrollHtmlAttributes] = GlobalUtils.useScroll();

Expand Down Expand Up @@ -166,3 +166,5 @@ export default function QuickStartComponent({ onHandleSampleClick }: Props) {
</React.Fragment>
);
}

export const QuickStart = QuickStartComponent
8 changes: 7 additions & 1 deletion src/frontend/src/containers/HomePage/children/index.js
@@ -1,5 +1,11 @@
import DiscoveriesCollection from './DiscoveriesTableContainer';
import ApplicationsTable from './ApplicationsTableComponent';
import PipelinesCollection from './PipelinesTableComponent';
import { QuickStart } from './QuickStartComponent';

export { DiscoveriesCollection, ApplicationsTable, PipelinesCollection };
export {
DiscoveriesCollection,
ApplicationsTable,
PipelinesCollection,
QuickStart
};
181 changes: 171 additions & 10 deletions src/frontend/src/index.mdx
Expand Up @@ -3,18 +3,179 @@ name: Getting Started
route: /
---

# Getting Started
import { Playground } from 'docz';

Design systems enable teams to build better products faster by making design reusableβ€”reusability makes scale possible. This is the heart and primary value of design systems. A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.
# LinkedPipes Applications Frontend

Regardless of the technologies and tools behind them, a successful design system follows these guiding principles:
Welcome to LinkedPipes Applications frontend documentation. This documentation is intented for developers looking for references about frontend implementation of the platform as well as details on code structure, coding conventions, **React component** design patterns and overview of **Components** and **Containers**.

- **It’s consistent**. The way components are built and managed follows a predictable pattern.
- **It’s self-contained**. Your design system is treated as a standalone dependency.
- **It’s reusable**. You’ve built components so they can be reused in many contexts.
- **It’s accessible**. Applications built with your design system are usable by as many people as possible, no matter how they access the web.
- **It’s robust**. No matter the product or platform to which your design system is applied, it should perform with grace and minimal bugs.
## Installation

## Consistency
The following set of tutorials is intented for developers aiming to:

Your first, most important task when starting out is to define the rules of your system, document them, and ensure that everyone follows them. When you have clearly documented code standards and best practices in place, designers and developers from across your organization can easily use and, more importantly, contribute to your design system.
- Work on contributing into our **Frontend** implementation of **LinkedPipes Applications** platform.
- Work on their own forked version, extend or expand the frontend for their own use-cases.
- Simply look for a reference documentation about certain components and their internal structure.

### Prerequisites

- [Yarn 1.17.0](https://yarnpkg.com)
- [Node.js v10.15.x](https://nodejs.org/en/)
- [Docker and Docker-compose](https://www.docker.com/) # if you intent to run via docker compose along with other containers

### Running locally

This assumes that you are currently inside the root folder of the whole application's repository and you have other components such as **Discovery**, **ETL**, **Backend** and etc. running locally in your system:

```bash

$ cd src/frontend
$ yarn install
$ yarn startLocalDevSockets

```

After that navigate to [localhost:9001](localhost:9001) to access the frontend served via `webpack-dev-server`.

#### Running locally without sockets

If you simply want to render the whole frontend without connecting to running instances of **Backend**, **ETL**, **Discovery** and databses, execute the following.

```bash

$ cd src/frontend
$ yarn install
$ yarn startLocalDev

```

Please, note that you won't be able to debug any functionality that requires other components of LinkedPipes Applications platform. This is mainly usefull for very specific cases when a UI of a component being developed needs to be debugged without wasting resources on other components running within `docker-compose`.

### Running with docker-compose

This assumes that you are currently inside the root folder of the whole application's repository.

```bash

$ docker-compose up --build --force-recreate

```

After that navigate to [localhost:9001](localhost:9001) to access the frontend, by default docker is being exposing it on port `9001` .

#### Running with docker-compose with persistent volumes

If you use the default `docker-compose.yml` file you will notice that it does not specify the volumes for **PostgreSQL** and **Virtuoso** containers. Therefore, your data won't be lost upon every `docker-compose up` session. If you want to have persistend docker-compose setup, follow these steps instead:

```bash

$ docker-compose -f docker-compose-persistent.yml up --build --force-recreate

```

This will create two folders named `data` and `appdata` inside the root folder of the repository. This is where your data is going to be stored for next `docker-compose up` sessions.

## How we structure the project

The structure below explains the main project structure that you should get familiar with:

```
β”œβ”€β”€ assets # Files, SVGs, PNGs all goes here and loaded by webpack file-loader
β”œβ”€β”€ docs # Usually generated during runtime of `docz:build` command and contains a static `docz` website that hosts this documentation.
β”œβ”€β”€ public # Generated by webpack when production is build, this hold the React Web App.
β”œβ”€β”€ src # The root of the React codebase, the implementation of frontend is hosted here
β”œβ”€β”€ components/ # Contains all minor UI components used withing LPApps frontend. For instance, buttons, toggles, appbars and etc.
β”œβ”€β”€ containers/ # Contains assembled web pages. We call this folder containers because it mostly hosts platform specific set of React components representing individual web pages. We also tend to declare a separate component that manages all the states called `Container`, while **Component** serves as a stateless component only responsible for rendering and manipulating props.
β”œβ”€β”€ constants # Contains various variables and constants used throughout frontend implementation.
β”œβ”€β”€ ducks # A duck is a Redux pattern that structures the actions, reducers and selectors within the same folder or a file, allowing easier manipulation over Redux states. Therefore, folder contains main Redux related logic.
β”œβ”€β”€ layouts # Contains several simple stateless components that wrap components that are passed to it. This allows easy customization of each individual webpage being routed from `AppRouter`. Things like, NavigationBar and SideBar are all assembled via layouts.
β”œβ”€β”€ storage # Contains an independent set of components and folders with its own structure, responsible for everything related to storing, manipulating, publishing and removing Application configurations from SOLID servers.
β”œβ”€β”€ utils # A set of various utility and helper functions and methods.
β”œβ”€β”€ AppRouter.jsx # Main component that manages the 'react-router' 'BrowserRouter' and 'socket.io' connections.
β”œβ”€β”€ store.jsx # Configures redux `store` for all `redux` states in the application.
β”œβ”€β”€ withRoot.jsx # A custom component that wraps around root component and sets custom `Material-UI` themes.
β”œβ”€β”€ wrapper.js # A custom wrapper component used for this `docz` documentation that simulates a root component plugged to `redux` and `react-router`.
└── index.jsx
β”œβ”€β”€ .babelrc
β”œβ”€β”€ .eslintrc.json
β”œβ”€β”€ .dockerignore
β”œβ”€β”€ .gitignore
β”œβ”€β”€ .prettierrc
β”œβ”€β”€ Dockerfile # Dockerfile used for development build images
β”œβ”€β”€ Dockerfile-prod # Dockerfile used for production build images
β”œβ”€β”€ doczrc.js # Configuration for styling and plugins for this documentation website
β”œβ”€β”€ Dockerfile # Dockerfile used for development build images
β”œβ”€β”€ jsconfig.json # Specifies aliases to root folders for easier import statements using webpack
β”œβ”€β”€ nginx.conf # Nginx configuration used for cases when frontend is a container inside docker-compose environment deployed on `applications.linkedpipes.com` server
β”œβ”€β”€ webpack.config.js
└── yarn.lock
```

## Designing the React component

Every component in LinkedPipes Applications frontend consist of two main folders. **Components** and **Containers**. **Components** usually contain elements that used in more than one webpage throughout the project, such as buttons, switches, image wrappers and etc. **Containers** represent complex react components that are basically rendering individual webpages or sub-elements of webpages that deal with complex user interaction use-cases.

## Simple components

Whenever an individual component needs to be implemented and it will be used in multiple webpages throughout the project, it is being placed into **Components** folder.

There are two main types of components that can be placed into **Components** folder and have different design conventions.

1. Simple stateless component responsible for rendering
2. A complex component that needs to aggregate multiple sub-components, manage redux, manage internal states and etc.

Whenever a component needs to be implemented and it falls into first category, a corresponding **.jsx** file being created following certain naming convention that is not strict but highly recommended:

```
[(Optional) Type of a component, Button/Switch etc][Name of an abstraction that it represents]Component.jsx
```

Whenever a component needs to be implemented and it falls into second category, a corresponding pair of components is created. Those can be described as follows:

1. Stateless react component responsible for props and rendering sub-components with a following naming convention,

```
[(Optional) Type of a component, Button/Switch etc][Name of an abstraction that it represents]Component.jsx
```

2. A **Pure** React component that manages **redux**, material-ui **styles** and its internal **states** that are passed as props to the statless component. It usually has the following naming convention for a file,

```
[(Optional) Type of a component, Button/Switch etc][Name of an abstraction that it represents]Container.jsx
```

To recap this sub-section, whenever a component gets complex, we simply tend to split into separate component responsible for rendering and a separate component callsed **container** that manages the states of the statless component. This allows easier navigation within the project as well as faster code debugging.

For more examples simply explore the **Components** folder.

## Complex components

Containers folder follows similar naming conventions to **Components** folder, the only difference is that it only hosts very specific and complex React components that usually represent the whole Webpage.

Whenever such component is being implemented, a corresponding set of files is created inside a sub-folder following this naming convention,

```
[Name of the feature representing the webpace]Page/
```

The components inside those folders all follow the same convention described in **Components** sub-section, meaning that it is always splitted into two **.jsx** files where one is managing state and the other manages rendering. The only difference is that the title of the file starts with the name of the feature that represents the webpage.

The diagram below recaps the described component design convention for splitting the single component into a pair of stateless and stateful components.

<img src="https://imgur.com/A8XeTTG.png" />

For more examples simply explore the **Containers** folder.

## Coding conventions

Refer to the **.eslintc.json** configuration for all information about `Javascript`, `ES6` and `React` coding conventions used within the project.

## Material-UI

Frontend implementation heavily utilizes the [Material-UI](https://material-ui.com) react framework. This allows faster and easier web development and component implementation. For more details about stock Material-UI component refer to their [component examples and documentation](https://material-ui.com/components/box/).

## What's next ?

If you want to explore the individual **Components** and **Containers** refer to the corresponding sections on this website. Each component details page allows you to browse through the main **props** being used as well as a live component example, that you can fork into an isolated **CodeSandbox** environment and play with different configurations.

If you want to learn more about more generic components of LinkedPipes Applications platform, such as **Discovery**, **ETL** or our **Backend** refer to a [User oriented documentation](http://docs.applications.linkedpipes.com) and/or [Backend documentation](http://docs.backend.applications.linkedpipes.com).

0 comments on commit 4b07ea1

Please sign in to comment.