|
@@ -1,14 +1,15 @@
|
|
|
# Porter Frontend Contribution Guide
|
|
# Porter Frontend Contribution Guide
|
|
|
|
|
|
|
|
|
|
+The purpose of this guide is to provide guidance on the development of the trickier parts of Porter's current frontend.
|
|
|
|
|
+
|
|
|
|
|
+## Getting Started
|
|
|
|
|
+
|
|
|
### Components
|
|
### Components
|
|
|
|
|
|
|
|
#### Functional Components and Migration
|
|
#### Functional Components and Migration
|
|
|
|
|
|
|
|
Currently, most of the frontend is written using Class Components. If you contribute to any part of the frontend, you are encouraged to rewrite any class component into a functional component. While doing so, keep a few things in mind:
|
|
Currently, most of the frontend is written using Class Components. If you contribute to any part of the frontend, you are encouraged to rewrite any class component into a functional component. While doing so, keep a few things in mind:
|
|
|
|
|
|
|
|
-#### Context
|
|
|
|
|
-
|
|
|
|
|
-If a prop is passed down more than three levels in the component heirarchy, it should be rewritten to be contained in a context. Make sure that all the components that then consume this context are functional, since the Context API isn't very good for class components.
|
|
|
|
|
|
|
|
|
|
#### Typing and Internal Organization
|
|
#### Typing and Internal Organization
|
|
|
|
|
|
|
@@ -30,6 +31,27 @@ const MyComponent: React.FC<Props> = (props) => {
|
|
|
}
|
|
}
|
|
|
```
|
|
```
|
|
|
|
|
|
|
|
|
|
+## Data Flow
|
|
|
|
|
+
|
|
|
|
|
+### Context
|
|
|
|
|
+
|
|
|
|
|
+If a prop is passed down more than three levels in the component heirarchy, it should be rewritten to be contained in a context. Make sure that all the components that then consume this context are functional, since the Context API isn't very good for class components.
|
|
|
|
|
+
|
|
|
|
|
+### Hooks
|
|
|
|
|
+
|
|
|
|
|
+One of the advantages of using react 16+ is the posibility to create custom hooks, so if you feel that something could be easier or you could reduce the repetition of logic by using custom hooks we encourage you to do so!
|
|
|
|
|
+
|
|
|
|
|
+#### Where should I place my new hooks
|
|
|
|
|
+
|
|
|
|
|
+If the hook that you're creating may be used all over the application you can add it to the `src/shared/hooks` folder, if not, you can place them right next to the components that will be using the hooks.
|
|
|
|
|
+
|
|
|
|
|
+#### Typing and documentation
|
|
|
|
|
+
|
|
|
|
|
+Please note that every hook that you may create will be used by other people, so typing it and adding comments on how it works/why you create such hook is super useful and we encourage this behaviour.
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+## Routing
|
|
|
|
|
+
|
|
|
### Routing model for new standard:
|
|
### Routing model for new standard:
|
|
|
|
|
|
|
|
The idea is to keep something similar to what NextJS or Angular+2 with submodules does, if we have a route the folder structure should try to respect that path
|
|
The idea is to keep something similar to what NextJS or Angular+2 with submodules does, if we have a route the folder structure should try to respect that path
|
|
@@ -70,26 +92,23 @@ We should end with the following structure
|
|
|
All first level routes should have it's own folder as it may be considered a new module of the application, inside each module we may have specific components we don't wanna share between modules, those should be named with an underscore first to be clear that they're not pages but simple components.
|
|
All first level routes should have it's own folder as it may be considered a new module of the application, inside each module we may have specific components we don't wanna share between modules, those should be named with an underscore first to be clear that they're not pages but simple components.
|
|
|
In the case that the Routes.tsx on the module became too long, it can be divided into subroutes inside the subfollowing folders.
|
|
In the case that the Routes.tsx on the module became too long, it can be divided into subroutes inside the subfollowing folders.
|
|
|
|
|
|
|
|
-### Hooks
|
|
|
|
|
-
|
|
|
|
|
-One of the advantages of using react 16+ is the posibility to create custom hooks, so if you feel that something could be easier or you could reduce the repetition of logic by using custom hooks we encourage you to do so!
|
|
|
|
|
-
|
|
|
|
|
-#### Where should I place my new hooks
|
|
|
|
|
-
|
|
|
|
|
-If the hook that you're creating may be used all over the application you can add it to the `src/shared/hooks` folder, if not, you can place them right next to the components that will be using the hooks.
|
|
|
|
|
-
|
|
|
|
|
-#### Typing and documentation
|
|
|
|
|
-
|
|
|
|
|
-Please note that every hook that you may create will be used by other people, so typing it and adding comments on how it works/why you create such hook is super useful and we encourage this behaviour.
|
|
|
|
|
|
|
+## Advanced
|
|
|
|
|
|
|
|
### Forms
|
|
### Forms
|
|
|
|
|
|
|
|
|
|
+Porter allows developers to build customizable forms on top of Helm by adding an optional `form.yaml` file to any Helm chart. Currently, forms can write to any field specified in a chart's `values.yaml`. We are working to add support for user-defined applets that can directly perform CRUD operations on cluster resources.
|
|
|
|
|
+
|
|
|
On the frontend, there are two components responsible for making forms work and are separated such that one only handles
|
|
On the frontend, there are two components responsible for making forms work and are separated such that one only handles
|
|
|
the form logic while the other does the rendering. The first one is `PorterFormContextProvider`,
|
|
the form logic while the other does the rendering. The first one is `PorterFormContextProvider`,
|
|
|
which provides a context that the second component `PorterForm` subscribes to using a custom hook.
|
|
which provides a context that the second component `PorterForm` subscribes to using a custom hook.
|
|
|
This relationship should be kept in mind when adding new functionality to this system: logic and rendering must be
|
|
This relationship should be kept in mind when adding new functionality to this system: logic and rendering must be
|
|
|
separated between these components.
|
|
separated between these components.
|
|
|
|
|
|
|
|
|
|
+### Debugging Forms
|
|
|
|
|
+
|
|
|
|
|
+To get an easy-to-access version of the form component with all the relevant props
|
|
|
|
|
+already passed in for you, navigate to a project dashboard and press and hold `command+k+z`;
|
|
|
|
|
+
|
|
|
### Form State
|
|
### Form State
|
|
|
As a whole, the frontend form stores its state in three places:
|
|
As a whole, the frontend form stores its state in three places:
|
|
|
1. The variables of the form - these are shared and can be modified by any form field
|
|
1. The variables of the form - these are shared and can be modified by any form field
|