Fix type propagation in ToStringOperation

[abulvenz]

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Does your submission pass the tests?

closes #3890

[abulvenz]

@benedikt-bartscher I haven't had a look into our PositiveInt class so far. Maybe ToNumberOperation can also be enhanced by a similar change.

[benedikt-bartscher]

@benedikt-bartscher I haven't had a look into our PositiveInt class so far. Maybe ToNumberOperation can also be enhanced by a similar change.

I see no good reason to not propagate the specialized type for ints as well

[abulvenz]

When looking into NumberOperations I found this asymmetry. Maybe that would be an even better fix?
@benedikt-bartscher @masenf Can somebody judge this?

        if issubclass(fixed_type, bool):
            return self.to(BooleanVar, self._var_type)
        if issubclass(fixed_type, (int, float)):
            return self.to(NumberVar, self._var_type)
        if issubclass(fixed_type, dict):
            return self.to(ObjectVar, self._var_type)
        if issubclass(fixed_type, (list, tuple, set)):
            return self.to(ArrayVar, self._var_type)
        if issubclass(fixed_type, str):
            return self.to(StringVar)   # var_type not propagated here !!!
        if issubclass(fixed_type, Base):
            return self.to(ObjectVar, self._var_type)
        return self

[benedikt-bartscher]

When looking into NumberOperations I found this asymmetry. Maybe that would be an even better fix? @benedikt-bartscher @masenf Can somebody judge this?

        if issubclass(fixed_type, bool):
            return self.to(BooleanVar, self._var_type)
        if issubclass(fixed_type, (int, float)):
            return self.to(NumberVar, self._var_type)
        if issubclass(fixed_type, dict):
            return self.to(ObjectVar, self._var_type)
        if issubclass(fixed_type, (list, tuple, set)):
            return self.to(ArrayVar, self._var_type)
        if issubclass(fixed_type, str):
            return self.to(StringVar)   # var_type not propagated here !!!
        if issubclass(fixed_type, Base):
            return self.to(ObjectVar, self._var_type)
        return self

I am not (yet) deep into the new var system, but that sounds like a better approach, and it seems like you already migrated to it?

[abulvenz]

Mmh, locally the integration-app-harness tests are passing.

[benedikt-bartscher]

Mmh, locally the integration-app-harness tests are passing.

you need to merge main, fixed in #3902

[abulvenz]

Thanks @masenf and @benedikt-bartscher. Now I can sleep peacefully 😃

[SadeghPouriyanZadeh]

what is ToStringOperation? i got this datatype in my app state all the time!
for exmpple when i int(MyState.my_property), i get this error.

int() argument must be a string, a bytes-like object or a real number, not 'ToStringOperation'

[abulvenz]

@SadeghPouriyanZadeh

what is ToStringOperation? i got this datatype in my app state all the time! for exmpple when i int(MyState.my_property), i get this error.

int() argument must be a string, a bytes-like object or a real number, not 'ToStringOperation'

What is a bit hard in the beginning is to understand that there are two types of code.
Runtime and Compile-Time.

Runtime is everything that is carried out in/via event handlers on state.
Those are nowadays marked using @rx.event.
In those methods your code should work using self, e.g.

class MyState(rx.State):
  my_property: rx.Field[str] = rx.field("123")
  @rx.event
  def calculate_int_like_crazy(self):
     print(int(self.my_property))  # At runtime type(self.my_property) == str

@rx.page
def index():
  return rx.box(MyState.my_property) # At compiletime type(MyState.my_property) == ToStringOperation 

All stuff that is evaluated during compile time is baked into the JS that renders the frontend. So sometimes it is better to do some calculations there. Have a look at @var_operations and FunctionVar (I hope I remembered them correctly, don't know if they are already in the docs, but definitely they are in the tests).