Define UI specifications for each invest model

[davemfish]

Each model can have a JSON specification to define the relationships among individual input fields in that model's setup. The design doc for this feature: https://docs.google.com/document/d/1VYOoHYXV7gIf2VQaiphC9ahr8zOtbeETQRESQtyvEmg/edit#heading=h.9r56n017eqt4

Things that can be controlled:

• order of the arguments
• grouping of arguments
• argument dependencies - where the state of one argument controls whether it's dependent args are hidden/disabled.
• always-hidden arguments

A few models already have specs (e.g. https://github.com/natcap/invest-gui/blob/master/ui_data/natcap.invest.ndr.ndr.json).

I can commit boilerplate specs for all other models, but then we'll need to populate those with values. These specs are not required for a functional application, but do provide a nicer user-experience.

[davemfish]

• [x] carbon
• [ ] coastal_blue_carbon
• [ ] coastal_blue_carbon_preprocessor
• [ ] coastal_vulnerability
• [ ] crop_production_percentile
• [ ] crop_production_regression
• [ ] delineateit
• [ ] finfish_aquaculture
• [ ] fisheries
• [ ] fisheries_hst
• [ ] forest_carbon_edge_effect
• [ ] globio
• [ ] habitat_quality
• [ ] habitat_risk_assessment
• [ ] hydropower_water_yield
• [x] ndr
• [ ] pollination
• [x] recreation
• [ ] routedem
• [ ] scenario_generator_proximity
• [ ] scenic_quality
• [ ] sdr
• [ ] seasonal_water_yield
• [ ] urban_cooling_model
• [ ] urban_flood_risk_mitigation
• [ ] wave_energy
• [ ] wind_energy

[emlys]

Just started on this but before I get too far, what would you think about refactoring the UI spec order option a bit? Right now the order is determined by a decimal number where the integer part is the section, and the decimal part is the place within that section. E.g. "order": 0.3 means the 3rd item in the 1st section (if I'm understanding correctly).

To me it might make more sense to have a separate "order" section in the top-level of the JSON. Something like:

{
    "order": [
        ["workspace_dir", "results_suffix"],
        ["lulc_cur_path", "carbon_pools_path"],
        ["calc_sequestration", "lulc_fut_path", "lulc_cur_year", "lulc_fut_year"],
        ["do_redd", "lulc_redd_path"],
        ["do_valuation", "price_per_metric_ton_of_c", "discount_rate", "rate_change"]
    ],
    "workspace_dir": {},
    "results_suffix": {},
    "lulc_cur_path": {},
    "calc_sequestration": {
        "ui_option": "disable",
        "ui_control": [
            "lulc_fut_year",
            "lulc_cur_year",
            "lulc_fut_path"
        ]
    },
    "do_redd": {
        "ui_control": [
            "lulc_redd_path"
        ]
    },
    "do_valuation": {
        "ui_control": [
            "rate_change",
            "discount_rate",
            "price_per_metric_ton_of_c"
        ]
    },
    "lulc_fut_path": {
        "ui_option": "disable"
    },
    "lulc_redd_path": {
        "ui_option": "disable"
    },
    "carbon_pools_path": {},
    "lulc_cur_year": {
        "ui_option": "disable"
    },
    "lulc_fut_year": {
        "ui_option": "disable"
    },
    "price_per_metric_ton_of_c": {
        "ui_option": "disable"
    },
    "discount_rate": {
        "ui_option": "disable"
    },
    "rate_change": {
        "ui_option": "disable"
    }
}

Benefits I see are:

• Makes for a slightly shorter JSON file
• Since the ordering is meant to be relative to the other fields, grouping into lists like this is a bit more intuitive to my brain
• Avoid possible edge cases with order numbers: do we count from 0 or 1? Does it matter? Can we skip numbers? Are negative numbers OK? What happens if two fields accidentally get the same order number?
• We could mark an argument as "hidden" by simply leaving it out of the "order" section

I may be missing something though. Are there possible future options that are better represented with the numeric ordering? Would love to hear your thoughts @davemfish

[davemfish]

I think these are all great points! I'm guessing we'll end up with cleaner, simpler code in the form components as well if we do this. I'm all in favor. Like you say, it's probably wise to do the refactor first with the few UI specs that are already checked in, and developing against the tests in setuptab.test.js, and then get that PR'ed before diving back into adding more models. Would you like to work on that refactor, @emlys ?

I think the main requirements for this feature are the 4 bullet points from the opening post on this issue. Another requirement we've kept thus far is that all model forms should still work without a UI spec. But that requirement could be open for debate, once all the models have a spec file.

[emlys]

@davemfish happy to work on it! Thanks for the input :)

[emlys]

This is now being resolved in https://github.com/natcap/invest-workbench/pull/84

[davemfish]

And #84 is done!