Implement new MultiEntry component #13

2025-10-16T16:14:03Z

BobdaFett commented

2025-10-16 16:14:03 +00:00

(Migrated from github.com)

What's Changed:

This new-and-improved MultiEntry component uses the new ValueType system to enter extendable entry maps into the overall ExpandableInfo struct. The MultiEntry stores a fairly hard to follow structure inside this struct, with that data being a ValueType::List(Option<Vec<ValueType::Map(Option<HashMap<String, ValueType>>)>>).

To make using this structure easier, I've made it so that the MultiEntry component itself handles only the top-level ValueType::List structure. This component will work exclusively with this list just to make sure that it is the correct type and that it is updated properly.

The second half of the structure is used exclusively in the Entry component. This component handles each individual ValueType::Map contained within the master list. Each component updates their own map.

To link all these together and allow updates to the master data_map structure (which is a standardized name across all input components) both the MultiEntry and Entry components have an associated Effect. This Effect is triggered in two different ways:

Entry: when the ValueType::Map is altered by entering new information into the component
MultiEntry: when any Entry changes their ValueType::Map
This means that the Entry components trigger changes in the MultiEntry component, which then triggers another change in the data_map signal. This allows the data to be consistent across all levels of the application.

What can be done further:

The ability to expand/collapse each individual Entry component would be nice, as this means the whole MultiEntry component will not take up the user's whole view. The second half of this is that we would want to truly make use of the name_member and info_member props - these were originally added so that the developer would be able to define a location in the map for the "name" of the entry. This hasn't been implemented, but I've left the props there as a reminder.

## What's Changed: This new-and-improved `MultiEntry` component uses the new `ValueType` system to enter extendable entry maps into the overall `ExpandableInfo` struct. The `MultiEntry` stores a fairly hard to follow structure inside this struct, with that data being a `ValueType::List(Option<Vec<ValueType::Map(Option<HashMap<String, ValueType>>)>>)`. To make using this structure easier, I've made it so that the `MultiEntry` component itself handles *only* the top-level `ValueType::List` structure. This component will work exclusively with this list just to make sure that it is the correct type and that it is updated properly. The second half of the structure is used exclusively in the `Entry` component. This component handles each individual `ValueType::Map` contained within the master list. Each component updates their own map. To link all these together and allow updates to the master `data_map` structure (which is a standardized name across all input components) both the `MultiEntry` and `Entry` components have an associated `Effect`. This `Effect` is triggered in two different ways: - `Entry`: when the `ValueType::Map` is altered by entering new information into the component - `MultiEntry`: when any `Entry` changes their `ValueType::Map` This means that the `Entry` components trigger changes in the `MultiEntry` component, which then triggers another change in the `data_map` signal. This allows the data to be consistent across all levels of the application. ## What can be done further: The ability to expand/collapse each individual `Entry` component would be nice, as this means the whole `MultiEntry` component will not take up the user's whole view. The second half of this is that we would want to truly make use of the `name_member` and `info_member` props - these were originally added so that the developer would be able to define a location in the map for the "name" of the entry. This hasn't been implemented, but I've left the props there as a reminder.

meraghon (Migrated from github.com) approved these changes

2025-10-23 15:09:16 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: r15-software-dev/scholarships-rs#13