mirror of
https://github.com/almet/notmyidea.git
synced 2025-04-28 11:32:39 +02:00
Add videos inside the source
This commit is contained in:
parent
9b117a8e75
commit
e8d48a9dfc
2 changed files with 33 additions and 30 deletions
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Adding collaboration on uMapn, third update
|
||||
title: Adding collaboration on uMap, third update
|
||||
tags: umap, geojson, websockets
|
||||
status: draft
|
||||
---
|
||||
|
@ -8,19 +8,21 @@ I've spent the last few weeks working on [uMap](https://umap-project.org), still
|
|||
with the goal of bringing real-time collaboration to the maps. I'm not there
|
||||
yet, but I've made some progress that I will relate here.
|
||||
|
||||
## JavaSript modules
|
||||
## JavaScript modules
|
||||
|
||||
uMap is an "old" project. It's been there [since 2012](https://github.com/
|
||||
uMap has been there [since 2012](https://github.com/
|
||||
umap-project/umap/commit/0cce7f9e2a19c83fa76645d7773d39d54f357c43), at a time
|
||||
when ES6 [wasn't out there yet](https://fr.wikipedia.org/wiki/ECMAScript#ECMAScript_Edition_6_(ES6)
|
||||
when ES6 [wasn't out there yet](https://fr.wikipedia.org/wiki/ECMAScript)
|
||||
|
||||
As a result, it wasn't possible to use JavaScript modules, nor modern JavaScript
|
||||
syntax.
|
||||
At the time, it wasn't possible to use JavaScript modules, nor modern JavaScript
|
||||
syntax. The project stayed with these requirements for a long time, in order to support
|
||||
people with old browsers. But as time goes on, we can now have access to more features.
|
||||
|
||||
The team has been working hard on bringing modules to the mix, and it
|
||||
wasn't a piece of cake. But, the result is here: we're [now able to use modern
|
||||
JavaSript modules](https://github.com/umap-project/umap/pull/1463/files) and we
|
||||
are now more confident about which features of the languages we can use or not.
|
||||
are now more confident [about which features of the languages we can use or
|
||||
not](https://github.com/umap-project/umap/commit/65f1cdd6b4569657ef5e219d9b377fec85c41958)
|
||||
|
||||
---
|
||||
|
||||
|
@ -30,7 +32,9 @@ use a bundler, which we aren't currently.
|
|||
|
||||
uMap is plain old JavaScript. It's not using react or any other framework. The way
|
||||
I see this is that it makes it possible for us to have something "close to the
|
||||
metal", if that means anything when it comes to web development.
|
||||
metal", if that means anything when it comes to web development. We're not tied
|
||||
to the development pace of these frameworks, and have more control on what we
|
||||
do. It's easier to debug.
|
||||
|
||||
So, after making tweaks and learning how "modules", "requires" and "bundling"
|
||||
was working, I ultimately decided to take a break from this path, to work on the
|
||||
|
@ -38,18 +42,13 @@ wiring with uMap. After all, CRDTs might not even be the way forward for us.
|
|||
|
||||
## Internals
|
||||
|
||||
So, I went for the deep dive into uMap internals. To be frank, I was expecting
|
||||
this to be hard : there is a lot of code, some legacy, and at first I was the
|
||||
head under the water, not able to understand how all this code was working together.
|
||||
|
||||
After some time, I can now wrap my head around the logic of the project. As one
|
||||
could expect, it's not the complexity that was overflooding me, but the fact
|
||||
that it's sometimes not simple to get the big picture. To phrase it otherwise,
|
||||
it was easy to get lost into the details.
|
||||
I was not expecting this to be easy and was a bit afraid. Mostly because I'm out of my
|
||||
comfort zone. After some time with the head under the water, I'm now able to better
|
||||
understand the big picture, and I'm not getting lost in the details like I was at first.
|
||||
|
||||
Let me try to summarize what I've learned.
|
||||
|
||||
uMap apears to be doing a lot of different things, but in the end it's:
|
||||
uMap appears to be doing a lot of different things, but in the end it's:
|
||||
|
||||
- Using [Leaflet.js](https://leafletjs.com/) to render *features* on the map ;
|
||||
- Using [Leaflet Editable](https://github.com/Leaflet/Leaflet.Editable) to edit
|
||||
|
@ -249,10 +248,6 @@ this.updateObjectValue(this.map, key, value)
|
|||
this.map.renderProperties(key)
|
||||
```
|
||||
|
||||
<video controls width="80%">
|
||||
<source src="https://files.notmyidea.org/umap-minisync.webm" type="video/webm">
|
||||
</video>
|
||||
|
||||
## Syncing features
|
||||
|
||||
At this stage I was able to sync the properties of the map. A
|
||||
|
@ -268,26 +263,34 @@ That seems a good place to do the changes.
|
|||
|
||||
I did a few changes:
|
||||
|
||||
- Each feature now has an identifier, so clients know they're talking about the same thing. This identifier is also stored in the database, so that persisted GeoJSON don't have to recreate ids.
|
||||
- I've added an `upsert` verb, because we don't have any way (from the interface) to make a distinction between the creation of a new feature and its modification
|
||||
|
||||
The way we intercept the creation of a feature (or its update) is to use Leaflet Editable's `editable:drawing:commit` event. We
|
||||
just have to listen to it and then send the appropriate messages !
|
||||
- Each feature now has an identifier, so clients know they're talking about the
|
||||
same thing. This identifier is also stored in the database when saved.
|
||||
- I've added an `upsert` verb, because we don't have any way (from the
|
||||
interface) to make a distinction between the creation of a new feature and
|
||||
its modification. The way we intercept the creation of a feature (or its
|
||||
update) is to use Leaflet Editable's `editable:drawing:commit` event. We just
|
||||
have to listen to it and then send the appropriate messages !
|
||||
|
||||
After some giggling around (ah, everybody wants to create a new protocol !) I
|
||||
went with reusing GeoJSON. It allowed me to have a better understanding of how Leaflet is using latlongs. That's a multi-dimensional array, with variable width, depending on the type of geometry and the number of points in each of these.
|
||||
went with reusing GeoJSON. It allowed me to have a better understanding of how
|
||||
Leaflet is using latlongs. That's a multi-dimensional array, with variable
|
||||
width, depending on the type of geometry and the number of shapes in each of
|
||||
these.
|
||||
|
||||
Clearly not something I want to redo, so I'm now reusing some Leaflet code, which handles this serialization for me.
|
||||
|
||||
I'm now able to sync different kind of features with their properties (the video is just showing points, but it's also working with polygons and polylines)
|
||||
I'm now able to sync different types of features with their properties.
|
||||
|
||||
<video controls width="80%">
|
||||
<source src="https://files.notmyidea.org/umap-sync-features.webm" type="video/webm">
|
||||
<source src="/images/umap/sync-features.webm" type="video/webm">
|
||||
</video>
|
||||
|
||||
## What's next ?
|
||||
|
||||
While I'm able to sync map properties, features and their properties, I'm not yet syncing layers. That's the next step! I also plan to make some pull requests with the interesting bits I'm sure will go in the final implementation:
|
||||
While I'm able to sync map properties, features and their properties, I'm not
|
||||
yet syncing layers. That's the next step! I also plan to make some pull
|
||||
requests with the interesting bits I'm sure will go in the final
|
||||
implementation:
|
||||
|
||||
- adding ids to features
|
||||
- having a way to map properties with how they render the interface
|
||||
|
|
BIN
content/images/umap/sync-features.webm
Normal file
BIN
content/images/umap/sync-features.webm
Normal file
Binary file not shown.
Loading…
Reference in a new issue