feat: trigger a calculated property on mutation

[FabienArcellier]

implement FabienArcellier#37

Simple subscription

def _increment_counter(state):
    state['my_counter'] += 1

_state = wf.init_state({"a": 1, "my_counter": 0})
_state.subscribe_mutation('a', _increment_counter)

_state['a'] = 2 # trigger _increment_counter mutation

Subscription on state with strong type

class MyState(wf.WriterState):
  counter: int
  total: int

def cumulative_sum(state: MyState):
  state.total += state.counter

initial_state = ss.init_state({
    "counter": 0,
    "total": 0
}, schema=MyState)

initial_state.subscribe_mutation('counter', cumulative_sum)

initial_state['counter'] = 2 # trigger the function cumulative_sum

Calculated property

class MyState(wf.WriterState):
    counter: int

    @wf.property('counter')
    def counter_str(self) -> str:
        return str(self.counter)

state = wf.init_state({'counter': 0}, MyState)

state.counter = 2 # trigger mutation for +counter_str 

Subscription with an event handler

def _increment_counter(state: RootState, context: dict, payload: dict, session: dict, ui: wf.WriterUIManager):
	if context['event'] == 'mutation' and context['mutation'] == 'a':
		if payload['previous_value'] < payload['new_value']:
			state['my_counter'] += 1

state = wf.init_state({
	"a": 1, 
	"my_counter": 0,
})

state.subscribe_mutation('a', _increment_counter)

In preparation of dot support expression

def cumulative_sum(state):
    state['total'] += state['a.b']

initial_state = wf.init_state({
    "a.b": 0,
    "total": 0
})

initial_state.subscribe_mutation('a\.b', cumulative_sum)

[FabienArcellier]

This way of doing things is too light.

I will have to check the arguments exposed on the handler here. To be consistent, it would be necessary to inject a payload with the previous value and the current value, add the ui and add a context which indicates the mutation causing the change.

[FabienArcellier]

• check that the signature of a property is valid (a single self argument), otherwise display a warning and ignore it
• check the signature of mutation event (support of state, payload, context and ui)

[madeindjs]

If you want to support array, the path should be able to contain number since string can't be index

>>> obj = {"a": [1,2,3]}
>>> obj["a"]["0"]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers or slices, not str

[madeindjs]

This doesn't handle key containing . .

Also, it doesn't work with Array index because the path_parts is an array of string (see my comment below)

IMO

• it should handle a path like this one foo["bar.baz"][0] we might need a library to handle it
• Or we should only accept array of string/number like ["foo", "bar.baz", 0]
• Or we considerate it's OK, but it might need a comment in the doc saying this limitation

[FabienArcellier]

usage of . into a state key trigger errors. That's a good point, we don't manage properly the case where a state contains . in the key. Currently it raise many issue.

I would advocate to manage the character . as reserved keyword for State key. We should ignore this value and show warning when the application is loaded.

mutation of State are not monitored on list : the State structure on the backend side supervises mutations exclusively on dictionaries, not on lists. This is an intrinsic limitation of WF.

A developer has to reassign a list to trigger the mutation. This point is covered in the Mutation detection in doc. It is therefore not possible to subscribe to a mutation on an element of a list.

[madeindjs]

Clear, thanks for the explanations.

About array, is it something we want to support ? Use case I see is to watch array elements in an array to get the sum. Something like this

class MyState(wf.WriterState):
  arr: List[int]
  total: int

def cumulative_sum(state: MyState):
  state.total = sum(state.arr)

initial_state = ss.init_state({
    "arr": [1,2,3,4],
    "total": 0
}, schema=MyState)

initial_state.subscribe_mutation('counter', cumulative_sum)

initial_state['counter'][0] = 9

[FabienArcellier]

I thin this question has already been debated in the past. I don't find trace about that. I think we decided that for the moment we wanted to avoid this pattern. Re-encoding a list as an observable object would have an overhead that we want to avoid.

In Python, lists are more often reconstructed rather than modified.

However, this was before the existence of typed states. Typed states allow you to specify how to behave with respect to a collection. I wonder on which usecase we would benefit from implementing this pattern.

[ramedina86]

That was a tough read but looks good to me. Should I merge?

[FabienArcellier]

That was a tough read but looks good to me. Should I merge?

You should