– next sprint completed

For we have chosen Openlayers framework instead of Leaflet used for project and had to integrate it with the React. Of course we knew about existing openlayer react npm, but as i am always trying to eliminate possible risks there was a decision to do not use unknown layer over unknown framework and do not bloat our code with the stuff we can not manage well.

So currently we have exactly two React components related to Openlayers: Map and RoadbookRoute and the layout looks like:

And the Map itself:

Pretty clean, huh?

The next decision is about domain components and models. There was a temptation to create a lot of components related to the entities: marker, track, passage, etc, but it was decided to keep the presentation layer closed to the Openlayer terms and live with Layers and Features only, but keep the logic within MobX stores.
In the other case we would have to spent lot of time just for typing log of “class extends…” without visible benefits. Moreover we would have invented our own “Presentation Description Language” and made us to maintain it and newcomers to learn it. Disgusting.

Thus our Route Layer gets the “model” store as a param created by MobX from its context:

and iterate over available route items existing in the model in order to build the openalyer’s features:

Pay attention we do not overuse JS classes (i.e. compare our own “type” field instead of “typeof” builtin) because we know MobX plays well with the plain object but there may be unpredictable behaviour of the JS class instances (namely in the part of the persistence). Once again – our goal is to complete the project in the predictable time and we avoid the risks as much as we can.

It is interesting the render method always returns false – indeed we do not render anything. Openlayer does it for us. It may be arguable – should we create the features within the render method or within for example in didUpdate. There are 2 reasons to use the first one.

First is a “beauty” – we are still rendering the features from the model. Is not it the method render good place for this? Second is risks once again: it is not clear completely would MobX call properties change related methods properly? Say 99% it will. But what about 1% MobX devs would decide to call forceUpdate in some circumstances? Why should we accept this low probability but having great impact risk instead of getting rid of it?

And final question is – if we create the openlayer feature from the model without creating the component and do not subclassing or something how would we keep the model related details in the feature? The answer is very simple – Openlayers showed itself as extremely professional and thought ahead framework and it provided neat feature: anything passed to the Feature constructor besides the mandatory arg geometry

will become “properties” and may be accessed by its name:

It the code above the SVG image is created on the fly as a feature marker by modifying the string template with the color attribute of the pin model stored within feature‘s properties list.

Leave a Reply

Your email address will not be published. Required fields are marked *