State Record Hooks

This is a hook inspired from this article. It greatly simplifies all behaviors regarding form inputs and value changes.

---

• provide a parallel interface where every state fields are a Toestand Box (difficult)
• using SProxy to avoid the unsafeSet

About Modals

By any means: avoid modal whenever it is possible

1. difficult to maintain, as each FFI library as its share of "how-to", most of times it lacks of what another can do (and vice-versa)
2. not a separate component logic / not a fully inherent member of a parent component logic, its hybridness is technically handicapping
3. idem, but with a UI/UX point of view: is the modal content a new page? or is it a fully wrapped-isolated page (such as an iframe)?
4. unwanted added complexity, this is a common smelly situation: when we use a modal in a page, it is anticipated that actions made within it will have a consequence on the host page itself. Which behaviors should be taken into account:
   • when the modal is still there (ie. by making some UI feedbacks behind the modal)?
   • or waiting for the modal to be closed?

How to limit the use of modals:

• Keep It Simple Stupid: limit the use of actions, so that just an alert component type would be truly fit for the purpose (such as "react-material-ui" dialogs ; or "vue-bootstrap" sidebar)
• YAGNI: just simply don't, prefer a change of component within the page (such as the project "Authentication" page)

React StateHooks & Toestand APIs & vanilla values

What Toestand API offers:

• an interface as the like of "react-usestateref"
• as well as PureScript-friendly methods (read more details on the Gargantext project guide)

At what point Toestand would not be beneficial? Short answer: choose Toestand where you were familiar with useState or useRef

• any kind of smart state logic should be covered via Toestand
  • cf. the different Stores examples, each store relies on it
  • cf. some Hooks logic (eg. "FormValidation")
• common use of StateHooks for component state instanciation can be replaced with Toestand
  • uniformisation topic: it is best to stick with Toestand API for every component state instanciations
  • example with useState :

component :: R.Component Props
component = R.hooksComponent cname cpt where
  cpt props _ = do
    -- (StateHooks API)
    -- count /\ setCound <- R.useState 0
    
    -- Toestand API
    count /\ countBox <- UI.useBox' 0

    ...

• dumb component and logic
  • as the likes of React useRef, Toestand Box adds more inherent complexity than just simple vanilla value
  • the case where one has to switch for Toestand Box * to a vanilla * is a pragramatic question left for the developer
  • dumb component inherits from light-or-no logic, so vanilla representation seems natural
  • low from mid complexity is a difficult case, for example the "FormValidation" Hook provides validation rule helpers for both Toestand Box and vanilla value

Bootstrap declarative classNames

At what point one can use Bootstrap className utilities or layouting? Short answer, don't use them.

• CSS Framework vs. customisation
  • this is a case of rigidity, as every classNames will be set on the DOM Element itself, priority issue can be raised (more details on CSS precedence)
  • hence, using this kind of utility to set the UI/UX of the webpage is a question of using it at all or not
  • the likes of Tailwind CSS provides a great CSS framework in this regards, whereas the one of Bootstrap feels less complete, sometimes clunky to use
  • for these reasons, it is best if we not using Bootstrap at all as a CSS framework for the project
• Quick CSS rule
  • it can be sometimes verbose when using BEM className pattern to add just a little padding on an isolated element
  • when experimenting this situation, Spacing bootstrap library is the only one that can be considered (remembering CSS precedence though)

<div class="block">
    <div class="block__element mt-2"></div>
</div>

Page/Layout pre-fetching & post-fetching

• Pre-fetching and UX/UI: As already describred in the "Components > Page and Layout structure, premount custom hook allows developer to perform a computation before any change of render. It will then block the user, and the native loading progress bar will display itself if a feedback is needed (more details on the Doherty Treshold UX design law)

• Post-fetching and UX/UI: On another side, one could use some placeholder components, as described in the "Component Cookbook", when the page is rendered and a some parts are visible to the user, some don't. During the computation process, fetching the needed data to fully display remaining parts, it is a best practice to show a kind of feedback of progression to the user rather than just a flickering or popping effect of the suddenly rendered components (more details on the Asthetic-Usability Effect UX design law)

• Note that both patterns can be applied for a given page/layout