DEV Community: priolo22

React clean with the STOREs

priolo22 — Thu, 26 Aug 2021 12:36:20 +0000

React is easy to use to create the "VIEW".
But when the application grows ... it's not enough!
Passing variables and methods in "props"
the code turns into leaves entangled in the nodes of the VIEW tree!

A practical example:

import { useState } from "react"

// main with "data"
export default function App() {
  const [data, setData] = useState(0)
  return (
    <div className="App">
      <ShowDataCmp data={data} />
      <ContainerCmp data={data} onChange={setData} />
    </div>
  )
}

// render data
function ShowDataCmp({ data }) {
  const renderData = `Data: ${data}`
  return <div>{renderData}</div>
}

// simple container
function ContainerCmp({ data, onChange }) {
  return <div style={{ background: "blue", padding: "5px" }}>
    <ChangeDataCmp data={data} onChange={onChange} />
  </div>
}

// component for change data
function ChangeDataCmp({ data, onChange }) {
  const handleOnClick = (e) => {
    const newData = data + 1
    onChange(newData)
  }
  return <button onClick={handleOnClick}>Change Data</button>
}

sandbox

Code and data are mixed in the VIEW.
If the application grows, you won't understand where the data and methods come from.
Let's face it: it's real shit!

Context

The Context is React's "native" solution.

Reworking the previous example we get:

import { createContext, useContext, useState } from "react"

const Context = createContext()

// main with "data"
export default function App() {
  const reducer = useState(0)
  return (
    <div className="App">
      <Context.Provider value={reducer}>
        <ShowDataCmp />
        <ContainerCmp />
      </Context.Provider>
    </div>
  )
}

// render data
function ShowDataCmp() {
  const reducer = useContext(Context)
  const renderData = `Data: ${reducer[0]}`
  return <div>{renderData}</div>
}

// simple container
function ContainerCmp() {
  return <div style={{ background: "blue", padding: "5px" }}>
    <ChangeDataCmp />
  </div>
}

// component for change data
function ChangeDataCmp() {
  const reducer = useContext(Context)
  const handleOnClick = (e) => {
    const newData = reducer[0] + 1
    reducer[1](newData)
  }
  return <button onClick={handleOnClick}>Change Data</button>
}

sandbox

Not bad! But there are two problems:

We have to create CONTEXT and STATE for each STOREs. If there were many STOREs the complexity would increase.
It is not clear how to divide the BUSINESS LOGIC from the VIEW

STOREs

There are tons of LIB out there!
If you want to stay light use JON
it's just a little sugar on "Native Providers"
... and heavily influenced by VUEX

Our example could be:

import { MultiStoreProvider, useStore } from "@priolo/jon"

const myStore = {
  // lo stato iniziale dello STORE
  state: {
    counter: 0
  },
  getters: {
    // 
    renderData: (state, _, store) => `Data: ${state.counter}`
  },
  actions: {
    increment: (state, step, store) => {
      store.setCounter(state.counter + step)
    }
  },
  mutators: {
    setCounter: (state, counter, store) => ({ counter })
  }
}

// main with "data"
export default function App() {
  return (
    <MultiStoreProvider setups={{ myStore }}>
      <div className="App">
        <ShowDataCmp />
        <ContainerCmp />
      </div>
    </MultiStoreProvider>
  )
}

// render data
function ShowDataCmp() {
  const { renderData } = useStore("myStore")
  return <div>{renderData()}</div>
}

// simple container
function ContainerCmp() {
  return (
    <div style={{ background: "blue", padding: "5px" }}>
      <ChangeDataCmp />
    </div>
  )
}

// component for change data
function ChangeDataCmp() {
  const { increment } = useStore("myStore")
  const handleOnClick = (e) => increment(1)
  return <button onClick={handleOnClick}>Change Data</button>
}

sandbox

state

The initial STATE of the STORE. "Single Source of Truth"
The STATE is connected to the VIEW (via React):
When the STATE changes then the VIEW updates automatically.

To access the STATE of a STORE:

const { state } = useStore("MyStore")

Avoid conflicts:

const { state:mystore1 } = useStore("MyStore1")
const { state:mystore2 } = useStore("MyStore2")

Outside the "React Hooks":

const { state:mystore } = getStore("MyStore")

Then:

<div>{mystore.value}</div>

getters

Returns a value of the STATE.
Although you can access the STATE directly
in many cases you will want some processed data.

For example: a filtered list:

const myStore = {
   state: { 
       users:[...] 
       }, 
   getters: {
      getUsers: ( state, payload, store ) 
         => state.users.filter(user=>user.name.includes(payload)),
   }
}

function MyComponent() {
   const { getUsers } = useStore("myStore")
   return getUsers("pi").map ( user => <div>{user.name}</div>)
}

The signature of a getter is:

state: the current value of the STATE
payload: (optional) the parameter passed to the getter when it is called
store: the STORE object itself. You can use it as if it were "this"

GETTERS should ONLY "contain" STATE and GETTERS

mutators

The only way to change the STATE.
It accepts a parameter and returns the "part" of STORE to be modified.

For example:

const myStore = {
   state: { 
       value1: 10,
       value2: "topolino",
    }, 
   mutators: {
      setValue1: ( state, value1, store ) => ({ value1 }),
      // ! verbose !
      setValue2: ( state, value, store ) => { 
          const newValue = value.toUpperCase()
          return {
              value2: newValue
          }
      },
   }
}

function MyComponent() {
    const { state, setValue1 } = useStore("myStore")
    return <button onClick={e=>setValue1(state.value1+1)}>
        value1: {state.value1}
    </button>
}

the signature of a mutator is:

state: the current value of the STATE
payload: (optional) the parameter passed to the mutator when it is called
store: the STORE object itself. You can use it as if it were "this"

Inside MUTATORS you should use ONLY the STATE.

actions

Contains the business logic
ACTIONS can be connected to SERVICEs and APIs
They can call STATE values, MUTATORS and GETTERS
They can be connected to other STOREs
They can be async

A typical use:

const myStore = {
    state: { 
        value: null,
    }, 
    actions: {
        fetch: async ( state, _, store ) => {
            const { data } = await fetch ( "http://myapi.com" )
            store.setValue ( data )
        }
    },
    mutators: {
        setValue: ( state, value, store ) => ({ value }),
    }
}

function MyComponent() {
    const { state, fetch } = useStore("myStore")
    return <button onClick={e=>fetch()}>
        value1: {state.value}
    </button>
}

the signature of a action is:

state: the current value of the STATE
payload: (optional) the parameter passed to the action when it is called
store: the STORE object itself. You can use it as if it were "this"

Conclusion

JON is designed to be VERY LIGHT and integrated with React.
Basically it is a utility to use native PROVIDERS
You can easily see them in the browser tool

Announcing: new and light state manager “Jon”

priolo22 — Wed, 21 Apr 2021 10:03:33 +0000

Introduction

So I started using the native REACT methods REDUCER and PROVIDERS for state management
... eventually I ended up with a light lib inspired by VUEX!
The great thing about VUEX (or FLUX) is that you have a solid structure:
The State is immutable,
The Actions change theState,
The View intercepts theState changes and calls the Actions.
Explicitly expressed by a simple object:

const store = {
    state: { ... },
    getters: { ... },
    actions: { ... },
    mutators: { ... },
}

The idea is of a "single source of truth" so I didn't use classes (which if I'm an OOP enthusiast)
as close as possible to REACT

I was surprised how useful it was in my projects so I decided to "publish" it:
Jon
I also made a template:
SPA-Template

Simple DEMO

Installation

npm install @priolo/jon

Create the store:

my_app/myStore.js

export default {
    state: {
        value: "init value",
    },
    getters: {
        getUppercase: (state) => state.value.toUpperCase(),
    },
    actions: {
        addAtEnd: (state, char, store) => {
            store.setValue(state.value + char)
        }
    },
    mutators: {
        setValue: (state, value) => ({value})
    }
}

Create PROVIDER

my_app/index.js

import React from "react";
import ReactDOM from "react-dom";
import App from "./App";

import { MultiStoreProvider } from '@priolo/jon';
import myStore from "./myStore"


const rootElement = document.getElementById("root");
ReactDOM.render(
  <MultiStoreProvider setups={{myStore}}>
    <App />
  </MultiStoreProvider>,
  rootElement
);

Use STORE

my_app/App.js

import { useStore } from "@priolo/jon";
import React from "react";

export default function App() {
  const { state, setValue, addAtEnd, getUppercase } = useStore("myStore")
  const handleClickIncrement = e => addAtEnd("!")

  return (<div>

      <h1>{state.value}</h1><h2>{getUppercase()}</h2>

      <input 
        value={state.value}
        onChange={(e)=>setValue(e.target.value)} 
      />

      <button 
        onClick={handleClickIncrement}
      >add !</button>

  </div>);
}

sandbox

Conclusion

The demo is very simple, but I've used Jon on fairly large projects and haven't regretted it.
Furthermore, they are simple PROVIDERS so for debugging you can use REACT Tool:

Let me know what you think!

Complete TEMPLATE for REACT SPA (2021)

priolo22 — Fri, 16 Apr 2021 14:09:48 +0000

Complete template for REACT SPA (2021)

INDEX

Startup
Store
CRA
AJAX
I18N
MOCK
ROUTING
UI COMPONENTS
URL
AUTH
TECNOLOGY
github
codesandbox
(in some cases MSW in sandbox does not work. Try open in new window)

STARTUP

This TEMPLATE allows you to derive a project in a fast and clean way.
You have full control of the code as it is a classic CRA.
Many typical management problems are solved in the template
and it can be a good way to learn.

clone:
git clone https://github.com/priolo/jon-template.git
enter:
cd jon-template
install npm modules:
npm install
install MSW
npx msw init public/ --save
run:
npm run start

The template is based on a library for managing the STORE in REACT:
Jon
and the concepts solved are:

STORE

When you use REACT for medium-large projects the first urgency is:

Separate the VIEW from the BUSINESS LOGIC
There are libraries for this! The most famous is REDUX
But, in my opinion, it is too long-winded and cumbersome.
So I started using the native REACT methods REDUCER and PROVIDERS
Eventually I ended up with a VERY VERY light bookcase inspired by VUEX!
Jon
Check it out!

CRA

There isn't much to say! If you want to make an app in REACT it is better to use CRA
You just don't have to manage babel andwebpack:
The APP will have a pre-established and reproducible setup.

components

it contains everything that is not a PAGE or DIALOG.
In general: conceptually "reusable" components.

hooks

Specific hooks used in the APP.

locales

The translation json for i18n

mock

ajax/handlers the functions for mock responses to HTTP requests
data the mock data to be used instead of the DB

pages

REACT components that rendering the "body" of the layout.
You intuitively start from the page, which is unique,
then go to the component that (theoretically) is used in several places.

plugin

They are services accessible at any point in the program. They allow you to access an external service, translate, make calculations etc etc

stores

They are the CONTROLLERs of the VIEWs.
The STORE is not the perfect solution but it works well in most cases!

BUSINESS LOGIC simply has to modify or read the STORE
without worrying about how VIEW is implemented.

It is ESSENTIAL for large projects because it allows you to:

distribute the code on several units, improving maintainability
clearly separates the VIEW from the BUSINESS LOGIC
you can modify the VIEW or the CONTROLLER (keeping the same BINDs) independently

Maintaining the APP after years or by several people is something to be expected.
Impossible if you have a tree of components that pass functions and properties to you making them highly context dependent.

Using the STOREs I can copy and paste a component to another point of the APP without problems.
components SHOULD HAVE NO PROPS
The components NOT HAVE PROPS (with the exception, of course, of "children" or "className").

Models and API

In reality in this TEMPLATE the APIs and the STOREs are "mixed"!
A questionable solution but given the simplicity of the API I didn't want to complicate the structure.
One could think of a "Models" folder for managing POCO objects
and "API" for HTTP requests.

AJAX

Being a SPA, all data arrives via AJAX.
I built a very simple class here.
I wanted a default SINGLETON SERVICE that could keep some properties (for example baseUrl)
But if necessary, since it is a class, several instances can be created.

I can use STORE even outside REACT (and therefore in SERVICE AJAX)

For example, here I set the STATE busy of the STORElayout when the SERVICE is busy:
in SERVICE (outside REACT)

// I download the "layout" store
const { setBusy } = getStoreLayout()
// if necessary set "busy" == true
setBusy(true)

While in the STORE layout

// I define the `busy` prop in readable / writable
export default {
    state: {
        busy: false,
    }.
    mutators: {
        setBusy: (state, busy) => ({ busy }),
    }
}

In VIEW
I can catch this event

function Header() {
    const { state: layout } = useLayout()
    return (
        <AppBar>
            {
                // In this case the "progress" is displayed if the SERVICE AYAX is busy
                layout.busy && <LinearProgress />
            }
        </AppBar>
    )
}

I18N

Sooner or later you will have to use it .... so better think about it first!
It's not just for "translating" the app
It allows you not to have the content directly in the VIEW ... which is more beautiful !!!
It is useful for testing in Cypress: you can use the translation PATH to locate components
instead of the text (which may change).

Inside a REACT COMPONENT
use the HOOK to import the t translation function

import { useTranslation } from 'react-i18next'
...
const {t} = useTranslation()

Translate via PATH

<TableCell>{t("pag.user.tbl.username")}</TableCell>

Or, outside of a COMPONENT, use the PLUGIN i18n

import i18n from "i18next"
...
const title = i18n.t("pag.default.dlg.router_confirm.title")

The translations are inside JSON files in the src\locales directory

doc

MOCK (MSW)

The APP must work offline! Of course with mock data

This allows to divide the tasks of those who do the FE and those who do the BE:
It is enough to share good documentation on the API (which must be done anyway)
You don't need the whole environment to develop.
It is also immediately "testable" (for example by Cypress).
Finally, the APP in mock can be presented as a demo to the CUSTOMER without "unexpected behavior" (= "panic")
Too many benefits!

I have configured and started MSW in /plugins/msw.js
It is called here starting a Service Worker

A Service Worker acts as a proxy between the APP and the WEB: "simulating" low-level network.
This is cool because it is completely transparent to the APP:
basically when you use fetch it still works ... even offline! The data is given to you by the Service Worker

In mocks/ajax/handlers there are simulated "CONTROLLERs"
In mocks/data there are ... the data! Used to emulate the DB

The APP starts the Service Worker if it is indevelopment or the REACT_APP_MOCK environment variable is" true "(string!)

Environment variables in CRA are documented here
However CRA (at compile time) takes from .env all variables that starting with REACT_APP
and makes them available in the browser

Example: To "simulate" the response to the request of a doc object by its id

HTTP request:
GET /api/docs/33

taken from: src/mocks/ajax/handlers/docs.js

import { rest } from "msw"
import list from "../../data/docs"

rest.get ('/api/docs/:id', (req, res, ctx) => {

    const id = req.params.id

    const doc = list.find(item => item.id == id)
    if (!doc) return res(ctx.status(404))

    return res(
        ctx.delay(500),
        ctx.status(200),
        ctx.json(doc)
    )
}),

ROUTING

Also in this case it is easy to choose: reactrouter

CONDITIONAL RENDER based on the current browser URL?

Use Switch by specifying one or more paths

/* ATTENTION: the order is important */
<Switch>
    <Route path={["/docs/:id"]}>
        <DocDetail />
    </Route>
    <Route path={["/docs"]}>
        <DocList />
    </Route>
    <Route path={["/", "/users"]}>
        <UserList />
    </Route>
</Switch>

CHANGE THE PAGE in REACT?

Use the useHistory HOOK:
src\components\app\Avatar.jsx

import { useHistory } from "react-router-dom";

export default function Avatar() {
    const history = useHistory()
    const handleClickProfile = e => history.push("/profile")
    return ...
}

CHANGE PAGE outside REACT?

Use the browser's native history

window.history.push("/docs/33")

Access the URL PARAMETERS?

Use the useParams HOOK.
src\pages\doc\DocDetail.jsx

import { useParams } from "react-router"

export default function DocDetail() {
    const { id } = useParams()

    useEffect(() => {
        if (!id) fetchById(id)
    }, [id])

    return ...
}

Confirm ON CHANGE

An example can also be found on the react-router-dom website here, I report it for completeness.

I created a custom hook useConfirmationRouter

that simply blocks navigation and asks for confirmation to continue.

I use it in the detail of the DOC here

WARNING
Being the TEMPLATE a SPA:

On URL change it does not make any HTTP requests to the server but simply updates the rendering

Of course, the data is always retrieved via AJAX requests

The only requests "about the APP structure" is the first loading or reload of the page.

The SERVER must be set appropriately to always reply with the same page

P.S.:
Are you like me? Is installing a plugin always a doubt? What if this library doesn't do what I need? What if it becomes obsolete the day after putting it into production? What if the author vows to God never to touch a pc again? What if I notice that there is an unsolvable BUG in the library? And then ... do you want to have full control of the software ??
So ... this plugin could be replaced by managing the url with the STORE.
But I will not cover the subject here :D

LAZY IMPORT

It is very very simple! If we have to create a portal with many pages
Even if we render only one page at a time

with the classic import we load ALL COMPONENTs! Even the ones the user will never see!
To load COMPONENTs only if necessary you need to use a native REACT function: React.lazy

I do it in the Main here

const DocDetail = lazy(() => import('../../pages/doc/DocDetail'))

export default function Main() {
    return (
        <Switch>
            <Route path={["/docs/:id"]}>
                <Suspense fallback={<div>LOADING...</div>}>
                    <DocDetail />
                </Suspense>
            </Route>
            ...
        </Switch>
    )
}

Suspense is also a native REACT component.
Allows you to view an alternate render while the component is loading.

UI COMPONENTS

Of course you can make your own components (it doesn't take much)
but Material-UI is very used and solid!
Nothing else is needed!

BINDING

First thing: link the STORE to the VIEW.
Remember useState BUT, instead of being in the COMPONENT REACT, it's in the STORE.

We define a STORE with a value in read / write

export default {
    state: {
        value: "init value",
    },
    mutators: {
        setValue: (state, value) => ({ value }),
    },
}

I import the STORE and "binding" of its value in the COMPONENT REACT

import { useStore } from "@priolo/jon"

export default function Form() {

  const { state, setValue, getUppercase } = useStore("myStore")

  return <TextField 
        value={state.value}
        onChange={e => setValue(e.target.value)}
    />
}

A sandbox (that does NOT use MATERIAL-UI)
To find out more, check out Jon

However, in this TEMPLATE you can find the BINDINGS everywhere

VALIDATOR

Form validation is always left for last 😄
There is a simple mechanism for validating Material-UI components.

Just connect a value to a rule (with a HOOK)
and assign the obtained props to the MATERIAL-UI component

import { rules, useValidator } from "@priolo/jon";

function Form() {

    const { state: user, setSelectName } = useAccount()
    // I create a custom "rule". If there is a violation I return a string with the error
    const customRule = (value) => value?.length >= 3 ? null : "Enter at least 3 letters."
    // I link two "rules" with the STORE ACCOUNT property "user.select?.name"
    const nameProps = useValidator(user.select?.name, [rules.obligatory, customRule])
    // ... and I get "nameProps"

    return <TextField autoFocus fullWidth
        // report an error if the value does not meet one of the rules
        {...nameProps}
        value={user.select?.name}
        onChange={e => setSelectName(e.target.value)}
    />
}

And validate in the STORE before sending the data

import { validateAll } from "@priolo/jon"

const store = {
    state: {
        select: { name: "" },
    },
    actions: {
        save: async (state, _, store) => {
            // check if there is an error in the displayed "rules"
            const errs = validateAll()
            // if there are errors I can view them ... or ignore them :)
            if ( errs.length > 0 ) return false
            // else ... save! 
        },
    },
    mutators: {
        setSelectName: (state, name) => ({ select: {...state.select, name} }),
    },
}

an example here

DYNAMIC THEME

Once you understand how the STORES work, you use them for everything
... of course also to manage the THEME

In the STORE layout I put everything that characterizes the general appearance of the APP
The THEME of MATERIAL-UI
but also the title on the AppBar, if the APP is waiting (loading ...), if the side DRAWERS are open, the main menu, the "message box", where the focus is set etc etc

However the THEME settings must be kept even when reload the page
The problem is that in this case the browser makes a new request to the server and the STORE is reloaded from scratch!
So I used the coockies to store the name of the selected THEME
you can see it here

The store theme is initially set with the cookie
and when the THEME is changed. (here)

export default {
    state: {
        theme: Cookies.get('theme'),
    },
    mutators: {
        setTheme: (state, theme) => {
            Cookies.set("theme", theme)
            return { theme }
        },
    }
}

Even if you use the cookies to memorize the name of the THEME
however, it is necessary to modify the STORE variable (more correctly "the STATE of the store")
Otherwise the VIEW does not receive the event!
In general the VIEW updates ONLY IF the state object of the STORE changes

Responsive Design

There are tools in MATERIAL-UI for this here
But what if we don't use MATERIAL-UI?

We can use the STORE! I initialize the STORE by hooking it to the window resize event

const store =  {
    state: {
        device: null,
    },
    // chiamato UNA SOLA VOLTA per inizializzare lo store
    init: (store) => {
        const checkDevice = ()=> {
            const deviceName = window.innerWidth < 767 ? "mobile" 
                : window.innerWidth < 950 ? "pad"
                : "desktop"
            store.setDevice(deviceName)
        }
        window.addEventListener("resize", (e) => checkDevice());
        checkDevice()
    },
    mutators: {
        setDevice: ( state, device ) => ({ device }),
    },
}

And I use it to modify the VIEW based on the device

function MainDrawer () {
    const { state: layout } = useLayout()
    const variant = layout.device == "desktop" ? "persistent" : null

    return (
        <Drawer
            variant={variant}
            ...
        >
            ...
        </Drawer>
    )
}

Of course you can also use it for: classes and style css or conditional render

URL

SEARCH AND FILTER

If I use a WEB APP and I copy the URL and send it to a friend

I expect him to see exactly what I see (with the same permissions of course)
Then the selected TABs, filters and sorting on the lists.

They must be kept in the search of the current URL (also called query string)
... in short, what is after the "?" in the URL

In STORE Route I can get or set a variable of query string which can be used in VIEW

An excerpt from the STORE:

export default {
    state: {
        queryUrl: "",
    },
    getters: {
        getSearchUrl: (state, name, store) => {
            const searchParams = new URLSearchParams(window.location.search)
            return (searchParams.get(name) ?? "")
        },
    },
    mutators: {
        setSearchUrl: (state, { name, value }) => {
            const queryParams = new URLSearchParams(window.location.search)
            if (value && value.toString().length > 0) {
                queryParams.set(name, value)
            } else {
                queryParams.delete(name)
            }
            window.history.replaceState(null, null, "?" + queryParams.toString())
            return { queryUrl: queryParams.toString() }
        },
    },
}

then I use it in the list to filter the elements

function DocList() {
    const { state: route, getSearchUrl } = useRoute()
    const { state: doc } = useDoc()

    // it is executed only if the filter or the "docs" changes
    const docs = useMemo (
        // actually I do this in the STORE DOC
        () => {
            // I get the "search" value in the current url 
            let txt = getSearchUrl("search").trim().toLowerCase()
            // I filter all the "docs" and return them
            return doc.all.filter(doc => !txt || doc.title.toLowerCase().indexOf(txt) != -1)
        },
        [doc.all, route.queryUrl]
    )

    // render of docs
    return {docs.map(doc => (
        ...
    ))}
}

meanwhile in the HEADER I have the text-box to modify the filter

import { useRoute } from "../../stores/route"

function Header() {
    const { getSearchUrl, setSearchUrl } = useRoute()
    return (
        <SearchBox
            value={getSearchUrl("search")}
            onChange={value => setSearchUrl({ name: "search", value })}
        />
    )
}

To recap: With the SearchBox I change the url
linked (via the store STORE route) to the VIEWDocList

and then this updates the list.
If I were to duplicate the page in the browser the filter would remain intact.

AUTH

The AUTH is not complete (a matter of time ... I'll finish it)!

It is managed by the STORE auth here

JWT (JSON Web Token)

How does it work?

This is a token (ie an "identifier string") that the server gives to the client when the client logs in successfully.

At this point the client at each subsequent request no longer has to authenticate,
but it just puts the token in the HEADER of the HTTPS request.

Or the server puts the token in an HttpOnly COOKIE, and will find it on every request.
In this case javascript will not be able to access the token (more secure)

The server seeing the correct token and assumes that that HTTP request was made by someone who has already passed authentication.

User data is directly in the token (including permissions): there is no need to query the db
The token have an "expiration" forcing the client to re-authenticate to generate a new token.
Of course you have to use an HTTPS connection to be safe.

Assuming you want to implement the token in the HEADER:
The ajax plugin includes the token if available here

import { getStoreAuth } from "../stores/auth"
...

export class AjaxService {
    ...
    async send(url, method, data) {
        const { state:auth } = getStoreAuth()
        ...

        const response = await fetch(
            url,
            {
                method: method,
                headers: {
                    "Content-Type": "application/json",
                    ...auth.token && { "Authorization": auth.token }
                },
                body: data,
            }
        )

        ...
    }
    ...
}

The token is accessible in the STORE auth.
I used cookies to avoid having to login again on "reload" (it does not work with MSW)

Cookies should only be used with HTTPS

import Cookies from 'js-cookie'

export default {
    state: {
        token: Cookies.get('token'),
    },
    getters: {
        isLogged: state => state.token != null,
    },
    mutators: {
        setToken: (state, token, store) => {
            if (token == null) {
                Cookies.remove('token')
            } else {
                Cookies.set('token', token)
            }
            return { token }
        },
    }
}

TECNOLOGY

Template di uno stack tecnologico
per realizzare un Front End SPA

React: you remove the PROPS!

priolo22 — Mon, 14 Dec 2020 08:26:15 +0000

In my experience the big problem I had by switching to REACT
is that it does not propose a global pattern to manage the business logic.

I have reviewed code where data and callbacks
have passed to an infinite series of components.
Any modification was a pain, especially to move a component out of its hierarchy.

REDUX is very interesting but too verbose for my style.

REACT provides "native" tools:
PROVIDER and REDUCER

but, in my opinion, they are too basic to use them directly.

So I wrote a "utility" (NOT a "library") served in several projects
very very light.

[https://github.com/priolo/jon]

Basic example:

Create STORE

my_app/myStore.js

export default {
    state: {
        value: "init value",
    },
    getters: {
        getUppercase: (state) => state.value.toUpperCase(),
    },
    actions: {
        fetch: async (state, payload, store) => {
            //const {response} = await ajax.get(`my_server`)
            //store.setValue(response)
        }
    },
    mutators: {
        setValue: (state, value) => ({ value }),
    },
}

Create PROVIDER

my_app/index.js

import React from "react";
import ReactDOM from "react-dom";
import App from "./App";

import { MultiStoreProvider } from '@priolo/iistore';
import myStore from "./myStore"


const rootElement = document.getElementById("root");
ReactDOM.render(
  <MultiStoreProvider setups={{ myStore }}>
    <App />
  </MultiStoreProvider>,
  rootElement
);

Use STORE

my_app/App.js

import { useStore } from "@priolo/iistore";
import React from "react";

export default function App() {

  const { state, setValue, getUppercase } = useStore("myStore")

  return (<div>
      <h1>{state.value}</h1><h2>{getUppercase()}</h2>
      <input onChange={(e)=>setValue(e.target.value)} />
  </div>);
}

online

Hope it's useful, I'm a huge fan of VUEX which I got my inspiration from
Bye!

Pssss...

However if (like me) you hate using too many external libraries
because you don't really know what they do
Check out this article:
REACT and STORE with HOOKS
It is "almost" the same thing directly with "Providers" and "useReducer"

REACT SPA structure

priolo22 — Thu, 29 Oct 2020 16:21:41 +0000

The rules

These are rules I use in my apps (mostly management software)
1) use as few libraries as possible
2) the VIEW must not contain code
3) use the STORE as CONTROLLER and possibly separate them from the BUSINESS LOGIC
4) the client must also work offline (mock)
5) of course: test

Technologies

We choose REACT.
I don't like REACT but, in my opinion, it's the best choice today.
Therefore:

CRA: God Facebook says: there is no need to think about it
use the STORE: on how to use them (in my opinion) I wrote this article
material-ui: is the most used: many "use cases" and documentation
react-router-dom: this is also used a lot ... you need a router!
cypress: you don't have to go crazy to create the test environment and it's absolutely "realistic". It works for any framework - it's worth learning
i18n: sooner or later it serves and in any case centralized texts are a good idea
(optional) mswjs: facilitates mocks to work even offline: rule 4

Basic implementation

on sandbox:

What you will find:

material-ui (material components)
It is a bit cumbersome for some things, for example the management of the Drawer.
But it is great for many others, for example managing styles and themes.

STORE centralize app status link article
codesandbox
In the example only the storeLayout is defined.
It keeps, for example, the status of the Drawer, side menu and the title of the ToolBar

ROUTING on the client with react-router-dom
codesandbox
Intuitive and use hooks.
I personally find the documentation a bit confusing.

What you will not find:

centralized component focus management in the STORE
dynamic change of the interface theme
handling of rendering errors (Error Boundaries)
mock (mswjs)
message box (you can't do without it!)
component validation (mandatory fields, password confirmation, etc etc ...)
route change validation (Preventing Transitions)
internationalization (i18n)
cypress test
separation of BUSINESS LOGIC from STORE

Which will be the next topics.
The idea is to grow this DEMO in order to create a complete APP

(Forgive my bad English)

REACT and STORE with HOOKS

priolo22 — Wed, 28 Oct 2020 08:00:30 +0000

A medium-large project MUST use STORE because:

VIEW separated from the MODEL
You can create reusable STORES to apply to different VIEWS
VIEW clean from code
NO passing parent-child events e NO long PROPS
Resources accessible from anywhere in the program
Centralized resources that are easy to maintain
Simplification of tests thanks to STATE

... MUST use the STORES !!!
Let's do it the way we like it:
without using a ton of frameworks!

Centralized management of DATA SOURCE

We want a DATA SOURCE accessible from any COMPONENTS
So: let's use PROVIDERS!
REACT has them, it would be rude not to

import React, { useContext, useState } from "react";
import ReactDOM from "react-dom";

// create CONTEXT
const MyContext = React.createContext();

// component that modifies the DATA SOURCE
function ChangeSource() {
    const [value, setValue] = useContext(MyContext);
    return <button onClick={(e) => setValue("value changed")}>Change</button>;
}

// component that displays the DATA SOURCE
function ShowSource() {
    const [value, setValue] = useContext(MyContext);
    return <div>{value}</div>;
}

// APPLICATION
function App() {
    // create DATA SOURCE
    const [value, setValue] = useState("start value");

    // application
    return (
        // instantiate CONTEXT
        <MyContext.Provider value={[value, setValue]}>
            {/* modify DATA SOURCE */}
            <ChangeSource />
            {/* view DATA SOURCE */}
            <ShowSource />
        </MyContext.Provider>
    );
}

ReactDOM.render(<App />, document.querySelector("#app"));

codesandbox

I create CONTEXT and DATA SOURCE
I insert the DATA SOURCE in the CONTEXT
I insert the CONTEXT in the APP (as PROVIDER)
And now I can access CONTEXT from any COMPONENT!
Once the CONTEXT has been obtained I can modify the DATA SOURCE
Changes are notified to the COMPONENTS that display the DATA SOURCE

All very nice!

Hook useReduce

For complexities greater than a single variable
it is convenient to use REDUCERS

import React, { useContext, useReducer, useState } from "react";
import ReactDOM from "react-dom";

// create CONTEXT
const MyContext = React.createContext();

// component that modifies the DATA SOURCE
function ChangeSource() {
    const [state, dispatch] = useContext(MyContext)
    const setValue1 = state => ({ ...state, value1: `${state.value1} changed`})
    const setValue2 = state => ({ ...state, value2: `${state.value2} changed`})

    return (<div>
        <button onClick={(e) => dispatch(setValue1)}>
            Change 1
        </button>
        <button onClick={(e) => dispatch(setValue2)}>
            Change 2
        </button>
    </div>);
}

// component that displays the DATA SOURCE
function ShowSource() {
    const [state, dispatch] = useContext(MyContext);
    return (<div> <div>{state.value1}</div><div>{state.value2}</div> </div>)
}

// simple reducer multipurpose :)
const reducer = (state, action) => action(state)

// APPLICATION
function App() {
    // create REDUCER (DATA SOURCE and DISPATCH)
    const [state, dispatch] = useReducer(reducer, {
        value1: "value 1",
        value2: "value 2"
    });

    // application
    return (
        // instantiate CONTEXT
        <MyContext.Provider value={[state, dispatch]}>
            {/* modify DATA SOURCE */}
            <ChangeSource />
            {/* view DATA SOURCE */}
            <ShowSource />
        </MyContext.Provider>
    );
}

ReactDOM.render(<App />, document.querySelector("#app"));

codesandbox

I replace "useState" with "useReducer"
Now I can "share" thanks to CONTEXT: STATE and DISPATCH
STATE contains a DATA SOURCE more structured
DISPATCH allows you to modify STATE with "pure functions"
The REDUCER simply passes the DATA SOURCE to the DISPATCH

that's all! You just have to "put in order"

Let's put it in order

Components are defined in external files
The STORE is defined in store.js

...easy

Use the STORE outside of REACT

Sooner or later it will happen! So it's best to think about it right away

I make the REDUCER global
When needed I apply the REDUCER to the STORE

Useful when I have some AJAX stuff and I have to put it in the STORE
(and I am not in a REACT-COMPONENT: no hook!)

Multi STORE

In the COMPONENTS (VIEW) THERE IS NO CODE !!! But only LOVE for the STORE

Yes I know: it looks like VUEX... I like VUEX!

(Forgive my bad English)

DEV Community: priolo22

React clean with the STOREs

Context

STOREs

state

getters

mutators

actions

Conclusion

Announcing: new and light state manager “Jon”

Introduction

Simple DEMO

Installation

Create the store:

Create PROVIDER

Use STORE

Conclusion

Complete TEMPLATE for REACT SPA (2021)

INDEX

STARTUP

STORE

CRA

DIRECTORY

components

hooks

locales

mock

pages

plugin

stores

Models and API

AJAX

I18N

MOCK (MSW)

ROUTING

CONDITIONAL RENDER based on the current browser URL?

CHANGE THE PAGE in REACT?

CHANGE PAGE outside REACT?

Access the URL PARAMETERS?

Confirm ON CHANGE

LAZY IMPORT

UI COMPONENTS

BINDING

VALIDATOR

DYNAMIC THEME

Responsive Design

URL

SEARCH AND FILTER

AUTH

JWT (JSON Web Token)

How does it work?

TECNOLOGY

MANAGE PROJECT

VIEW LIBRARY

STORE

COMPONENTS

ROUTER

INTERNAZIONALIZZATION

MOCK

TEST

React: you remove the PROPS!

Create STORE

Create PROVIDER

Use STORE

REACT SPA structure

The rules

Technologies

Basic implementation

What you will find:

What you will not find:

REACT and STORE with HOOKS

Centralized management of DATA SOURCE

Hook useReduce

Let's put it in order

Use the STORE outside of REACT

Multi STORE