---
# System prepended metadata

title: 'Client: Design gap analysis'

---

# Client: Design gap analysis

## :heavy_check_mark: State (XState)
XState has been introduced with  https://github.com/alkem-io/client-web/issues/893

#### State and Context
In the context of XState the term `state` represents one of the finite number of states in which the machine can be.

In the context of React `state` is private for a component and can be controlled only by the component and can be used to store different kind of data.

In React the `context` provides a way to pass data through the component tree without having to pass props down manually at every level.

The XState's `context` is similar to the Ract/Redux state.

#### Uses
- **components internal state** - XState provides more declarative way to describe the different states in which a component can be. This can be benefitial when complex components are being developed. 
- **container state** 
    - internal state - similar to the components internal.
    - fetching data - the XState provide side-effects out of the box (redux needs `sagas` or `redux-thunk`) and can be used for fetching data. This functionality has already been covered by ApolloGraphQL. However there might be some cases where we will need fetching data from third party APIs (Google Maps, etc.).

- **global state** - current use of XState is to handle a few global states. Showing/Hidding elements from the Navigation bar depending on location and the notification service which combines pushing and clearing notifications. Using XState for the last one is overkill. The notification service does not need a state and it just utilize the XState actions and context.

#### Organization

## Components
- [ ] Split big components to different parts:
    - [ ] containers (business logic) - if the business logic will be used in more than one container move it into a hook.
    - [ ] hooks (business logic)
    - [ ] presentational 
- [ ] Combine splitted components into views
- [ ] Reuse views in pages
- [x] Migration to material UI:
    - [x] update composite components to use material components (ex: formik inputs instead of rendering etc.)
    - [x] [theme definition](#Theme)
- [ ] layout - current structure has one main layout which is available on every page and a few small ones which are used in specific situations. Some pages might not need the same *main* layout like admin panel or authentication related pages.
    

## Context

- [ ] Identify crucial contexts and how they affect application loading and working:
    - [ ] configuration context
    - [ ] authentication/kratos context
    - [ ] graphql context
    - [ ] user context (currently logged user)
    - [ ] reorganize the ecoverses(plural) and the ecoverse(singular) contexts so unnecessary data loads are mitigated. 
    - [ ] Organization Context
    - [ ] Challenge context
    - [ ] Opportunity context

## Routing
- [ ] clean up routing.
    - [ ] move loading logic container, context or hook.
    - [ ] keep the router as simple as possible
    - [ ] investigate possibilities for generic router + configuration
- [ ] update the navigation/breadcrumb to work accordingly

## :heavy_check_mark: Theme
Define theme(s) using materil UI.

## Authorization
Needs deeper discussion!

## MUI (Formerly Material UI)


- [ ] Upgrade to MUI 5.0 With MUI 5 unstyled compnents are shipped which allows create complete theme from srach. The default MUI theme is still available
- [ ] Clean up core components (UX/UI Design needed!)
    - [ ] **Typography** - start using the MUI `Typography` component
    - [ ] **makeStyles** - use `makeStyles` instead of our `createStyles` - the last one is just an export of makeStyles.
    - [ ] **Cards** - migrate basic cards to relay on MUI `Card`
    - [ ] **Button**


## Testing
- [ ] Unit testing
    - [ ] presentational components
    - [ ] composites (example: `ApplicationButton`)
    - [ ] containers
    - [ ] hooks