Skip to content
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

feat: Added two more options to setvar. #3654

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

abulvenz
Copy link
Contributor

Either provide a dot-separated string to access
fields on objects or use a var to describe which
value to set.

This enables you to write something like this:

import reflex as rx

class Object(rx.Base):
    name: str = "1234"

class State(rx.State):
    message: str = "Default"
    object: Object = Object()

def index() -> rx.Component:
    return rx.container(
        rx.text(f"Object name: ", State.object.name),
        rx.input(value=State.object.name, on_change=State.setvar(State.object.name)),  # new syntax
        rx.input(value=State.object.name, on_change=State.setvar("object.name")),  #new syntax
        rx.text(f"Message: ", State.message),
        rx.input(value=State.message, on_change=State.setvar(State.message)),  # new syntax
        rx.input(value=State.message, on_change=State.setvar("message")),
    )

app = rx.App()
app.add_page(index)

It might need some polishing with regard to nonexisting fields on objects, which is not checked for now.
But I want to share a first version to get feedback.

Either provide a dot-separated string to access
fields on objects or use a var to describe which
value to set.
@masenf
Copy link
Collaborator

masenf commented Jul 10, 2024

use a var to describe which value to set

when i initially implemented setvar, this behavior was included, but a point was raised that it could introduce an incongruity and confusion.

consider the following code

rx.input(value=State.message, on_change=State.setvar(State.message))

it's not clear if i'm intending to set State.messages to the changed value, or if i'm trying to do indirection and set a var that is named the value of State.message to the changed value.

@benedikt-bartscher
Copy link
Contributor

benedikt-bartscher commented Jul 10, 2024

I still like "the State.a.set thing" #3163 (comment)
But, as @masenf pointed out, we need descriptor based vars and event handlers for this to pass type checkers.

@masenf
Copy link
Collaborator

masenf commented Jul 10, 2024

we need descriptor based vars and event handlers for this to pass type checkers

This is actually on the horizon. We're working on the Var refactor now and descriptor-based state Vars are part of that project.

@abulvenz
Copy link
Contributor Author

OK, I see. Sorry that I didn't do the history digging 👍

Thanks!

@abulvenz abulvenz closed this Jul 10, 2024
@masenf
Copy link
Collaborator

masenf commented Jul 10, 2024

to be clear, i still think State.setvar("object.name") is sweet! we should keep that.

@abulvenz
Copy link
Contributor Author

to be clear, i still think State.setvar("object.name") is sweet! we should keep that.

Ah, sorry, tiny misunderstanding 😄 , so we are still in the game 🎲 . With your suggested change we can still write something like the following, which can help when refactoring, but typing is a bit 💔, but of course we can use a little # pyright: ignore[my-typing].

  rx.input(
      value=State.object.name, on_change=State.setvar(State.object.name._var_name)
  )

@benedikt-bartscher Do you think this could still help then with our wild internal meta-programming dreams?

Or to help the confused API-users, we rename the function from setvar to apply_event_to or apply_value_to or apply_to and read this:
rx.input(value=State.message, on_click=State.apply_to(State.message))

@abulvenz abulvenz reopened this Jul 11, 2024
@Lendemor
Copy link
Collaborator

Marking this as draft until resynced with main.
Some of the recent addition for typing event handler might unblock this PR.

@Lendemor Lendemor marked this pull request as draft October 25, 2024 18:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants