Front-end UI commands hierarchy

Front-end UI commands hierarchy

Motivation

Most user actions cause non-trivial changes in underlying broser state. This

User actions

Sometimes user might perform the same action using different place of the visual user interface, using keyboard shortcuts or my some other action or inaction.

If app behavior differs because of HOW user performed the action then this code is perfect candidate to be located in the user action UI level of the application.

Sometimes two or more user action events might happend at once. For example. User click can cause focus out event on one input and focus in event on another input; so that’s three events at once.

Example

When user removes slide using menu and mouse then application shows corresponding keyboard shortcut. Showing the hint about the keyboard shortcut should be located in the user action layer of code.

Interface command

If you can think of some changes which happen together as a result of user action then it’s perfect candidate for a interface command pattern.

It’s ok to show hint or make advanced UI manipulations at this level. E.g.:

  • changing focus
  • canceling events

Examples

  • add new slide
  • go to the next slide
  • remove current slide

Operations. Safe changes of the state.

  • Operation is a single function responsible for the change of state of the app.
  • Operation code does not have access to UI, DOM or React. You can write text which would run in NodeJS environment. Some front-end is not possible to identically replicate at this level. For example, when user is switching focus from one element to another two differnt events and consequent operations might occur.
  • Every operation is to make sure to only switch application from one valid state to another valid state
export const goToFirstSlide = () => {
  setCharm(iterableSlideListState,
    ({ slideList, currentSlideIndex }) =>
      ({ slideList, currentSlideIndex: 0 })
  )
}

Operation example: Removing slide. It might seem to be very trivial operation but it has at least three possible controls flows:

  • Normal remove of the slide.

    Underlying code:

    1. create new list of slides which doesn’t contain the slide. Then set the new slide list instead of the old one.
    2. Save presentation.

  • Remove of the slide which is the last slide

    1. Create new list of slides which doesn’t contain the slide. The set the new slide list instead of the old one.
    2. If current slide index is bigger than the last slide list index then decrease current slide index by one.
    3. Save presentation

  • Attempt to remove the slide which is the only slide of the presentation

    1. This operation must not be completed
    2. The operation must throw error so the Interface command level might show the message that the slide can not be removed.

  • NOTE: Operation which removes slide but doesn’t check the current slide index must not exist.

Jotai atom set

The most raw set calls. Might be simple set value call. Or more complicated setter function calls.

Raw jotai manipulations:

  • might be dangerous

  • might place system into inconsitent state

  • Raw jotai manipulations should not be exposed above the Operations layer.

  • set slideList

  • set currentSlideIndex

Persist data to server