GeoHub Component design guide #1241
Replies: 2 comments
-
In addition to the above state management of No.6 on svelte/sveltekit, GeoHub also uses URL query params and page load data as state managements. These two state management methods are used in many places in GeoHub. For instance,
load dataFor page data, please refer the following URL. If Some of data can be directly accessed from components via page data. An example of geohub/sites/geohub/src/routes/data/+page.server.ts Lines 49 to 55 in a7bd62b An example of geohub/sites/geohub/src/routes/data/+page.svelte Lines 1 to 12 in a7bd62b query params between
|
Beta Was this translation helpful? Give feedback.
-
For maplibre's style state management, maplibre has new option of https://maplibre.org/maplibre-gl-js-docs/api/map/#map#setstyle |
Beta Was this translation helpful? Give feedback.
-
Main assumptions and facts
GeoHub leverages Maplibre GL to handle geospatial data visualization and svelte/sveltekit to create slick and reactive UI. Because Malibre Map has it's own lifecycle it is necessary to synchronize the lifecycle of svelte components with the lifecycle of the Map object.
There are a range of options that could be used to achieve this but the practicalities of developing components has shown not all to be reliable. These are the main assumptions and facts that underline this process:
a). simple props sharing
b). events -> child-parent and parent-child
c). svelte stores
Svelte component lifecycle
There are some specific aspects of how svelte components life-cycle happens and this has implication on how GeoHub components have to be designed. There are three main parts of a svelte component,
The most important part is the script and it features a specific execution order as follows:
GeoHub lifecycle
It is important to note the rendering happens between somewhere inside step three, theoretically before the beforeUpdate() and onMount().Geohub componets use a custom approach with a custom async method called init() wharred inside an await block. All of this is illustrated in the code below
This approach ensures the geoHub components are being initialized consistently.
Map <=> UI intercommunication
The interaction between the Maplibre and the UI is implemented through a series of utility functions. In general the communication goes
UI -> Map -> UI
There are directions modes of communications:
1. UI->Map
This functionality is implemented as an async utility function.
The most important section of the function are the last three lines. We can see the map is updated, and saved only after it is ready. This ensures that all reactive subscribers are notified with valid values.
2. Map -UI
This direction is covered by two specific functions targeting two different initialization modes: declarative/synchronous
and imperative/async
The functions performs exactly the same thing, the only difference being in the way they behave. The async function is designed to be fetch state in an imperative context or on demand and because of this it makes sure the map is loaded before it extracts the state. The declarative version assumes the map is loaded/ready and fetches the state from the map.
The last piece of the setup is the loadMap function
This is a small workhorse designed to be robust and and features some safety measures like a maximum amount of time to wait before it returns as not to get blocked.
Using reactivity and synchronization correctly will ensure the components are consistent and GeoHub behaves correctly and is predicatable, two very important features
Beta Was this translation helpful? Give feedback.
All reactions