All of our data is in the form HashMap<String, ValueType>. We will eventually want to create some sort of view for the data that just takes a map and a data member (like all other inputs in the forms) and displays the value from that specific entry.
There's a couple options for this as well, since the ValueType has several types, however I'm leaning more towards creating a single component that automatically resolves and displays the correct type. For example, if it's passed a data member that points to a ValueType::String, we'll just display a simple line of text. If it's pointing to a ValueType::List instead, then we'll show some sort of list appearance instead.
The point where this will require more planning is when a ValueType::List can contain a series of ValueType::Map, or just more ValueType::List. If we have these nested data structures, we'll have to find some way to display them in a way that makes sense. It's possible that we would want to create some prop that can check for a maximum depth, and only display until that point. However, we want this to still look right as well, and just cutting off at a specific depth could look sloppy because we lose out on data.
Overall, if this needs to be split into specific components then that's not a horrible thing - under the hood, it's likely just a single component that displays other components based on a match statement.
All of our data is in the form `HashMap<String, ValueType>`. We will eventually want to create some sort of view for the data that just takes a map and a data member (like all other inputs in the forms) and displays the value from that specific entry.
There's a couple options for this as well, since the `ValueType` has several types, however I'm leaning more towards creating a single component that automatically resolves and displays the correct type. For example, if it's passed a data member that points to a `ValueType::String`, we'll just display a simple line of text. If it's pointing to a `ValueType::List` instead, then we'll show some sort of list appearance instead.
The point where this will require more planning is when a `ValueType::List` can contain a series of `ValueType::Map`, or just more `ValueType::List`. If we have these nested data structures, we'll have to find some way to display them in a way that makes sense. It's possible that we would want to create some prop that can check for a maximum depth, and only display until that point. However, we want this to still look right as well, and just cutting off at a specific depth could look sloppy because we lose out on data.
Overall, if this needs to be split into specific components then that's not a horrible thing - under the hood, it's likely just a single component that displays other components based on a `match` statement.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
All of our data is in the form
HashMap<String, ValueType>. We will eventually want to create some sort of view for the data that just takes a map and a data member (like all other inputs in the forms) and displays the value from that specific entry.There's a couple options for this as well, since the
ValueTypehas several types, however I'm leaning more towards creating a single component that automatically resolves and displays the correct type. For example, if it's passed a data member that points to aValueType::String, we'll just display a simple line of text. If it's pointing to aValueType::Listinstead, then we'll show some sort of list appearance instead.The point where this will require more planning is when a
ValueType::Listcan contain a series ofValueType::Map, or just moreValueType::List. If we have these nested data structures, we'll have to find some way to display them in a way that makes sense. It's possible that we would want to create some prop that can check for a maximum depth, and only display until that point. However, we want this to still look right as well, and just cutting off at a specific depth could look sloppy because we lose out on data.Overall, if this needs to be split into specific components then that's not a horrible thing - under the hood, it's likely just a single component that displays other components based on a
matchstatement.