Frontend project plan

[heliocastro]

Introduction

To have a concise implementation of next frontend, we need start to set some basic ground rules. As the nature of the movement is somehow difficult, since we will be developing single pages in a collaborative mode, so elements need to be proper planned and designed.

Project Tasks

Initial tasks will be centered on page, subsequent component, utility, layout tasks should be created on demand

• Project SHOULD use own Github SW360-Frontend projects
• Project tasks SHOULD have an issue per task and subtask with assignment for at least one reviewer

Elements

As an initial approach based on the POC ideas ( Svelte previous ), there are four key elements to be treated:

• Pages
• Components
• Layout
• Core utility functions

Pages

Pages/Routes need to be treated as a singular entity, therefore the first skeleton of each page is a main task assigned to a single developer.

Each page element should be evaluated before usage, considering layout, component itself and utility functions. Decoupling the logic of work:

• Create a Task per page.
  • Page need a component -> Reuse global component OR create a Component task and start component development
  • Page need style -> See if style is global or specific -> If global, modify global style, if local, create style on local router.
  • Page need SSR -> Verify if request is global or specific -> Reuse utility function with request is exists or create new task for Utility
  • Page SHOULD NOT have layout elements in the router, it need to reuse global OR add the missing entities
  • Page has a function that can become an utility AND usage is more than once ( other pages ) SHOULD create a Task for Utility function and moved to there or created there

Components

Components should be individual entities not depending on core specific functionality, allowing to be reused throw entire app. Decoupling the logic of work:

• Create a Task for Component:
  • Did the component exists on current framework on available on the internet -> Reuse and apply global style or create subtask for the component development
  • Did the component is reactive -> Verify if SSR is needed and create proper task for Utility function
  • Create a subtask to generate Test for the component. No component task should be finished without proper testing

Layout and Icon/Graphics

Main layout need to be global and all elements need to be described in a single location. Specific CSS/Color/Font should not be allowed inside routing.

• Customize of layout SHOULD follow framework used rules
• Graphical objects SHOULD be in a text based format, preferred SVG and only bitmapped files allowed need to pass to careful review

Utility

Request and common functions should be united under single area, not specific to router pages, when is used more than one time.

• Utility tasks SHOULD have a testing subtask and no function should be released with test
• Utility functions SHOULD be written in Typescript
• Utility functions SHOULD not create dynamic layout or routings unless necessary
• Utility task REST related should have the SW3600 core REST backend side implementes until be finished otherwise task can't be done.

Code conventions

As no direct coding standard guidelines exists to React per se, we need set some basic conventions.

• Project need to be available since day zero with proper linter and commit convention checkers
• Project need follow single language
• Project need to do pre commit checks

Some single rules can be applied to current state:

• Project SHOULD use Typescript Reference guidelines
• Project SHOULD use conventional commits Reference guidelines
• Project SHOULD follow Next.js best practices as most as possible Next.js Docs
• Project SHOULD document all the stages, disregarding is Page, Component, Utility function or even layouting.

Developer Documentation

• TODO