Skip to content

Global State improvements

Jump to bottom
Palbolsky edited this page Feb 3, 2024 · 3 revisions

Currently the front-end knows about the entire state of the project. This may cause various amount of issues like rollbacks, too much back-end code in the front-end etc...

To improve that, we should make sure the front-end only knows about the state it needs to know about and ask the back-end for other states.

State the front-end needs

There's few things the front-end needs to know all time:

  1. If a project is currently loaded (no need to know the path, it's irrelevant)
  2. If there's stuff to save (Save button)
  3. The list of entities in current user's locale

Front-end also needs local states:

  1. The currently edited entity's data
  2. The list of entity relations in list page

State that the back-end needs

In the other hand, when loading a project, the back-end needs to load all the JSON files and few "CSV" (text) files. It may need additional state, here's the state the back-end needs:

  1. Project path (back-end must deny all queries if there's no loaded project)
  2. All entities data (when loaded or after save)
  3. Used text files
  4. All the map meta-data

What about changes

Generalities

One idea would have been to put all the changes in the back-end but it doesn't really make sense since Studio has a "Save button". That means until the user clicks this button, changes are not committed.

This means changes about list of entities, changes in entities and changes in texts must be stored in front-end. Those changes could be differences this way we would be able to use the CTRL-Z action (un-piling change from the change stack of the entity).

Problem with Map update

The map update is a process that reconstruct the map-info (RMXP) and the tiledMetadata field. In no case the tiledMetadata field should be edited by the front-end so the "Map Update" button should be a back-end action where the back-end do update this field.

The change stack about maps should only be about other fields than tiledmetadata. The front-end should perform a kind of save action when the tiledFilename is changed otherwise the back-end cannot do the right action. This needs to be defined UX wise/technically.

When the app is in RMXP mode, it should always ask the back-end about the map-info!

MapTree refresh

The MapTree is updated with a useEffect when an external modification is made (the MapTree has a clone of the mapinfo). So when we delete a map or a folder, for the space of an instant, the elements of the MapTree are rendered because their data depends on the global state. However, the map tree still has a copy of the mapinfo even though the maps no longer exist, hence the "deleted map". As soon as the useEffect is triggered, the structure is updated, so everything disappears and we return to a consistent state.

An approach using a useMemo instead of a useState has been tried but although it fixes this bug, the MapTree becomes unstable and adding maps does not cause a refresh.

Clone this wiki locally