| [23:32:31] | <symbioquine[m]> | <mstenta[m] "But for contrib modules: yea bes"> I think I've figured out a decent pattern for this: https://github.com/symbioquine/farmOS_vue_page_demo |
| [09:19:38] | * cpm has joined #farmos |
| [11:33:55] | <symbioquine[m]> | Building on that to start sketching out a land drawing tool for 2.x; https://github.com/symbioquine/farmOS_land_drawing_tool/tree/development |
| [11:34:02] | <symbioquine[m]> | ACTION uploaded an image: (124KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/HxaaguCBfPWBTDFa... > |
| [11:34:48] | <paul121[m]> | okay COOL! curious how/if (??) Vue can play with the map :-) |
| [11:35:26] | <symbioquine[m]> | The OpenLayers vector source is just an object so there's nothing stopping it from being reactive in Vue.js |
| [11:36:00] | <symbioquine[m]> | https://github.com/symbioquine/farmOS_land_drawing_tool/blob/b9f785aef20... |
| [11:36:28] | <symbioquine[m]> | https://github.com/symbioquine/farmOS_land_drawing_tool/blob/b9f785aef20... |
| [11:36:37] | <symbioquine[m]> | https://github.com/symbioquine/farmOS_land_drawing_tool/blob/b9f785aef20... |
| [11:40:21] | <paul121[m]> | ah cool.. was curious how it was interacting with the map instance... but it looks like you create it within the vue app, makes sense: https://github.com/symbioquine/farmOS_land_drawing_tool/blob/b9f785aef20... |
| [11:40:57] | <symbioquine[m]> | Yeah, that way the component can own the lifecycle of the map |
| [11:41:27] | <symbioquine[m]> | More critical in apps with routing where the map might need to get created/destroyed multiple times within a single "page instance" |
| [11:41:34] | <symbioquine[m]> | But still a good pattern |
| [11:41:58] | <paul121[m]> | bonus points if you can make it work with the map that Drupal creates :-) |
| [11:43:05] | <symbioquine[m]> | I considered that, but it would have been pretty hard to untangle that Drupal event subscriber stuff and get only the bits of behavior I need for this tool. |
| [11:43:29] | <paul121[m]> | (main thinking is so that other custom layers/behaviors could be included in this as well - certainly not critical) |
| [11:43:32] | <symbioquine[m]> | farmOS-map has a cleaner interface |
| [11:43:52] | <paul121[m]> | yeah |
| [11:44:20] | <symbioquine[m]> | <paul121[m] "(main thinking is so that other "> Yeah that makes sense, it's just hard to make stuff both globally automatic and modular/configurable... :) |
| [11:45:35] | <paul121[m]> | yea.. Drupal wasn't made for JS modularity! |
| [11:46:28] | <paul121[m]> | one idea tho, if you make a `map-type` config entity & render a map on a page via a Drupal controller, it should get a unique ID on the page. Could the Vue app "attach" to that? |
| [11:47:48] | <symbioquine[m]> | <paul121[m] "one idea tho, if you make a `map"> That would probably work, but at least there'd be some complicated state associated with hot reloading for development. |
| [11:48:52] | <symbioquine[m]> | With Vue managing the instance it's pretty much a live editing experience without even needing page reloads. |
| [11:49:30] | <symbioquine[m]> | https://github.com/symbioquine/farmOS_vue_page_demo/blob/release/README.... |
| [11:50:22] | <paul121[m]> | ooohhh yeah that would complicate hot reloading |
| [11:52:27] | <symbioquine[m]> | ACTION uploaded an image: (397KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/fZbHERuBcvhoElFq... > |
| [11:55:20] | <symbioquine[m]> | That said, it would be nice if there were a way for certain farmOS-map behaviors from relevant farmOS contrib modules to get automatically registered with tools like this. |
| [11:56:08] | <symbioquine[m]> | It's almost like we need some sort of tagging/scoping system so that the behaviors can control when they apply and map instances or pages can supply more metadata about themselves for that determination. |
| [11:58:17] | <symbioquine[m]> | That seems to be roughly the goal of that Drupal MapEvent system, but as-is you can't use it without pulling in a bunch of stuff that is (appears anyway) hard-coded for the scenario where Drupal is rendering the map component. |
| [12:01:29] | <paul121[m]> | > It's almost like we need some sort of tagging/scoping system so that the behaviors can control when they apply and map instances or pages can supply more metadata about themselves for that determination. |
| [12:01:29] | <paul121[m]> | yesss... had a few ideas on that here - it's necessary for supporting "multiple maps", but "multiple maps" can also mean maps being created/destroyed over the lifetime of a single page which is probably more common: https://github.com/farmOS/farmOS-map/issues/94#multiple-maps |
| [12:03:00] | <paul121[m]> | the "global behavior" registry might actually work well for this Vue app use case tho.. I *think* it would still add those behaviors to the map instance it's handling itself? |
| [12:03:17] | <paul121[m]> | but the issue with the global behaviors is they're always there, and always added |
| [12:04:29] | <symbioquine[m]> | See https://github.com/farmOS/farmOS-map/issues/110#issuecomment-830649430 |
| [12:04:47] | <paul121[m]> | if you enable `farm_mapbox` does it get added to this Vue app? |
| [12:05:15] | <symbioquine[m]> | no |
| [12:05:27] | <symbioquine[m]> | At least I'm pretty sure it wouldn't |
| [12:05:29] | <symbioquine[m]> | I can check |
| [12:05:53] | <paul121[m]> | ah right... because the map render event is when it's added to the page |
| [12:08:45] | <paul121[m]> | cool yea `namedBehaviors` is inline with what I was thinking :D |
| [12:09:50] | <paul121[m]> | a pattern I'm seeing though is that with the `attachBehavior(behavior, options = {})`, the `options` are different from what I've been referring to as "settings" |
| [12:10:43] | <paul121[m]> | `options` could certainly be used for "settings", but that hasn't been our practice haha |
| [12:10:57] | <paul121[m]> | I hadn't realized that before |
| [12:12:29] | <paul121[m]> | so the "farmOS-map API is complete", yes, but our Drupal implementation could be improved |
| [12:45:54] | <symbioquine[m]> | <paul121[m] "`options` could certainly be use"> The nice thing about this is that most of the settings don't need to change over the life of a map instance so a "constructor-based" model is much simpler. |
| [12:46:09] | <symbioquine[m]> | That said some mutable/observable state could be really nice too... |
| [12:47:23] | <symbioquine[m]> | Might make sense for them to be largely separate mechanisms though. |
| [12:47:24] | <paul121[m]> | true and true |
| [12:48:02] | <paul121[m]> | right... and theres nothing stopping a behavior from using `instance.map.set('myvalue', ..)` right now... |
| [12:48:03] | <symbioquine[m]> | Gotta go play outside now, but super excited to be talking through this stuff! |
| [12:48:38] | <paul121[m]> | guess its just a matter of how & if we should standardize something. hmm |
| [12:48:43] | <symbioquine[m]> | yeah |
| [12:57:11] | <mstenta[m]> | Haven't had a chance to respond but I've been enjoying reading all this! Great stuff!! |
