You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For context, I am developing a web application that processes CSV files for statistical analysis. The application follows multiple decision paths depending on data characteristics. For example, if the data is normalized, specific tests are applied; if not, different tests are implemented or user input is requested before proceeding. Each test may generate multiple outputs and might require linked inputs requiring separate cells, which may also reference each other.
I often end up needing to create nested form structures. Previously, I created a dictionary as suggested in the documentation and it renders perfectly fine using a combination of hstack and vstack. I then decided to render it as a form, which doesn't accept hstack or vstack. So, I attempted to render it using batch. The form method only accepts flattened inputs, which prevents me from nesting it. For instance, while you can reference name, you cannot use name["first"] or name["last"]. Instead, batch requires name_first and name_last, making nested dictionary processing more challenging. I would prefer if mo.md, when used with mo.batch, could accept dictionary-based formats and allow form usage without needing to convert flattened list of variables back to a nested dictionary.
As a follow-up point, based on the current implementation, I expected to access the value for changes in the submitted form using either form.value or the form_inputs.value, as dictionaries are designed to be reactive to changes. However, this isn't occurring, likely due to cloning when converting to a form. I'm unclear why this behavior differs, as form.value works while form_inputs.value doesn't.
Suggested solution
The most viable solution would be to enhance mo.md's rendering capabilities with batch to support dictionary-style key access. This would simplify form creation by eliminating the need for separate functions that flatten dictionaries for batch inputs and re-nest form values.
Alternatively, we could implement form creation with guardrails using submit and reset buttons. I am unsure if this would be more challenging to implement though but, it could offer easier improved layout flexibility (using hstack and vstack) compared to the currently needed HTML code.
Alternative
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
Thanks for sharing this use-case. Nested dictionaries would be nice for composition and modularity.
We do clone the element, hence the reactivity issue you are seeing. This also helps with composition/re-usability.
I think we can support dictionary access as a dot-path. Maybe instead of {name["first"]}, it would be {name.first}. The first looks like python, while the second is more common in templating languages and don't depend on the quote type.
I realized that the following code renders the form correctly (I didn't know Python's string format supported nested dictionaries like this). However, even after submitting the form, form.value remains empty.
I have a branch to fix this, but does complicate our logic quite a bit and may have some edge cases. I am putting it on pause, but let me know if this becomes a blocker.
Description
For context, I am developing a web application that processes CSV files for statistical analysis. The application follows multiple decision paths depending on data characteristics. For example, if the data is normalized, specific tests are applied; if not, different tests are implemented or user input is requested before proceeding. Each test may generate multiple outputs and might require linked inputs requiring separate cells, which may also reference each other.
I often end up needing to create nested form structures. Previously, I created a dictionary as suggested in the documentation and it renders perfectly fine using a combination of hstack and vstack. I then decided to render it as a form, which doesn't accept hstack or vstack. So, I attempted to render it using batch. The form method only accepts flattened inputs, which prevents me from nesting it. For instance, while you can reference
name
, you cannot usename["first"]
or name["last"]. Instead, batch requiresname_first
andname_last
, making nested dictionary processing more challenging. I would prefer ifmo.md
, when used withmo.batch
, could accept dictionary-based formats and allow form usage without needing to convert flattened list of variables back to a nested dictionary.The following code snippet works
The following code snippet doesn't work
As a follow-up point, based on the current implementation, I expected to access the value for changes in the submitted form using either
form.value
or theform_inputs.value
, as dictionaries are designed to be reactive to changes. However, this isn't occurring, likely due to cloning when converting to a form. I'm unclear why this behavior differs, asform.value
works whileform_inputs.value
doesn't.Suggested solution
The most viable solution would be to enhance
mo.md
's rendering capabilities withbatch
to support dictionary-style key access. This would simplify form creation by eliminating the need for separate functions that flatten dictionaries for batch inputs and re-nest form values.Alternatively, we could implement form creation with guardrails using submit and reset buttons. I am unsure if this would be more challenging to implement though but, it could offer easier improved layout flexibility (using
hstack
andvstack
) compared to the currently needed HTML code.Alternative
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: