search

ramp4-pcar4 / config-editor

A config editor for RAMP4.
1 stars 1 forks source link

Input and `i18n` refactor #57

Open mohsin-r opened 2 months ago

mohsin-r commented 2 months ago

RAMP4 Config Editor: Input and i18n refactor

What is this?

The original code for the config editor was written in a rush. As such, the inputs have a lot of duplicate code. Now that we are working towards switching all inputs from hardcoded English to i18n, this seems like a ripe opportunity to refactor input code and make it cleaner. This involves creating our own custom input.vue and checkbox.vue which has the code for handling all input types, the header, and the small information icon. Then, each input simply calls these components. Therefore, the number of lines of code for each input goes from approximately 4-5 -> 1-2. Another aspect of this refactor would be to update all v-model code to the new recommended defineModel() method.

Progress

This will track which files have completed the switch to i18n and custom input components.

james-rae commented 2 months ago

Ideas from a rarely-Vue and non-RESPECT dev.

  1. That's a LOT of files. Is it possible to just have a generic "config-ui" template that can be passed some sort of metadata definition object that tells it how to assemble itself? Sort of like what your doing here, but branched out to handle the generic control sets. I'm in no position to know what kind of roadblocks this would cause. Also could be you can't do that level of nesting (essentially having to name generic sub-templates in your metadata which then become real templates that bind correctly to the overall ramp config in the store). Anyway, all I'm really saying is from the outside it looks like this codebase is a lot of boilerplate with small tweaks to define it for each section of the config; if there's a nice way to remove it, great. If it's needed to keep things sane, all good.
  2. Does Respect Editor do anything similar to what your proposing? Or alternately can this approach be applied to the Respect Editor? Thought here is we should strive to have a unified development approach to both editors (and also apply to the soon to be built "Highchart Editor Resolving Many Accessibility Nuances" app). This means a dev who knows how to deal with one can pivot to the other two projects without needing to learn a new paradigm.
mohsin-r commented 2 months ago

That's a LOT of files. Is it possible to just have a generic "config-ui" template that can be passed some sort of metadata definition object that tells it how to assemble itself?

I had this idea in the beginning, where you'd pass in your schema into the component and it would auto build out the UI. Then the app would work even if we revamped the schema for whatever reason. Its difficult to say whether this is worth a shot, mainly because there are a ton of small edge cases that are coded in into the individual templates. You'd need a bunch of ifs for specific cases. For example, for every object you just need inputs for its fields, but then for extents, you also need the extent picker and linking between the map and config extent. Similarly, how would a generic editor code in an autolegend where you have a relationship between the layer and legend configs? We also have some lists that get converted to object key-value pairs, and so on. So the feeling I have is RAMP is too complex to have a generic nested object parsing UI template. This refactor attempts to take a middle ground, where boilerplate at the input level is abstracted out but we still parse the objects individually, if that makes sense.

Does Respect Editor do anything similar to what your proposing? Or alternately can this approach be applied to the Respect Editor? Thought here is we should strive to have a unified development approach to both editors

The feel of Respect is very different to this. The templates for each type of editor (map, image, slideshow, chart, etc.) are very different and there isn't really any duplicate/boilerplate code. Additionally, the RAMP schema is far more complex than the Storylines schema (and hence has a lot more inputs). The other thing is RESPECT is meant to be a standalone app, whereas this works as something that can be both standalone and embedded into something else. All these factors mean that unified development approach may not make sense. However, I agree that we should have this editor and the Highchart Editor be similar in their development approach.

A lot of the above thoughts are half-baked, so feel free to retort if anything is nonsense.