-
Notifications
You must be signed in to change notification settings - Fork 944
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add UserInputs component #1788
Merged
Merged
Add UserInputs component #1788
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why shouldn't the
value
be ause_state
hook?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant,
use_reactive
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strict rule here, but I try to follow a one-directional data flow model here.
JupyterViz
"owns" the state here, i.e. we just pass the current parameters down toUserInputs
. Any changes are brought back via theon_change
method and the parent component decides what to do with the changes.Contrast this with keeping the state inside UserParams. It wouldn't be clear how to extract the current value back to the parent component (JupyterViz) so we can act on a change. I don't know enough about how solara yet, so maybe this would also be possible. I am mainly following React best practices here - for a reference (and a great start to react in general) see https://react.dev/learn/thinking-in-react
Or maybe you meant something completely different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's in the very simplest example of Solara that you pass in reactive variable to the user input value: https://github.com/widgetti/solara/blob/master/solara/website/pages/examples/basics/sine.py. I find the
on_value
construct too convoluted, not to mention its nested functions for achieving the same functionality.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the question is where should that state live? In the sine example global state is used. Which I did in the previous iteration, where you - correctly - blamed me for it being not reusable that way.
I think the current way is very simple. At the top level we have the
model_parameters
state variable that is used for the model creation. Its a simple variable-value dictionary. And we have the list of user-settable parameters. This list is passed independently of themodel_parameters
toUserParams
. And any changes insideUserParams
are handled at the top level by updating themodel_parameters
. This way we have maximal reusability of theUserParams
component.Now if we were to define the reactive variables at the
JupyterViz
component and pass them toUserParams
we have a tight coupling between the user parameters and the model parameters and the logic resides both inJupyterViz
andUserParams
.UserParams
can't be used withoutmodel_parameters
although that dependency is not strictly required.And if we define the reactive variables inside
UserParams
than we are back to my problem of not knowing how to get the updated value back to the parent component.I fully agree that it appears a bit convoluted at first and especially the nested functions are not nice - in JS the function definition could simply be written as
(value) => (name) => on_change(name, value)
. I don't know if it would be possible to have a similar concise syntax in Python. But the important part is that it is not the same functionality. Just definingvalue
as a reactive value doesn't help us changing themodel_parameters
dictionary.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The nested functions are just one of the complications.
It's that you have to do
handle_*
at theJupyterViz
level, and do something along the line of subsequenton_change
's inside the subcomponents. Simpler would be to have this at the parent component, and at the last leg of the child component.I'm not sure what you meant by
UserParams
. Is it a hypothetical reactive variable, a Solara component, a class, or something else not yet implemented? If it is initialized insideJupyterViz
, why can'tJupyterViz
be notified of its change when you can add dosolara.use_reactive(..., on_change=do_something)
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry about the UserParams confusion. I meant the UserInputs component implemented in this PR.
It makes sense for the handle_ function to be at JupyterViz because it changes the model_parameters state - where else should that happen.
Frankly I don't understand the rest of your comment. Maybe it would be more productive if you could have some concrete advice on how to move forward. Is this blocking for this PR or could this be an improvement in a further PR? I am really not sure anymore what your critique revolves around and how to move on