fork-tongue / observ Goto Github PK

It would be useful to have more detailed info for watch callbacks on collections to have a better understanding what has changed. Currently, the callback for arrays yields new and old objects but they are usually the same because they point to the same object. I think this is also the case for dicts.

Especially for dicts it would be beneficial to know for which keys the values have changed, which key/value pairs have been added and which key/value pairs have been removed. For arrays the same applies, but then you would expect indices of course.

We need to use a threading.RLock to ensure thread safety when working with the globals:

I'm wondering what thread safety means in the context of observ...

1. Execute the wrapped func
2. Notify subscribers
3. Remove the dep

Allow the following type of constructions:

state = reactive({"text": "Hello, world!})

watch(state["text"], self.label.setText)  # instead of watch(lambda: state["text"], self.label.setText)

watch(state, expr, callback, **opts) would be a better API

Just to document how they are treated, and to verify that they work as expected and intended.

Blocked by #9 and #10

We might have the same issue as fork-tongue/collagraph#49

Need to define three methods:

• state = make_reactive(data)
• computed_prop = cached(prop_func)
• watch(state['prop'], callback)

It should be (relatively) easy to also add readonly(state) which would provide a proxy onto an observable that throws an error on any write operation.

https://v3.vuejs.org/guide/reactivity.html#proxy-vs-original-identity

Let's add some tests to see how this works for us.

See numpy/numpy#16712

I've been thinking and it just makes more sense to have deep=True as a default on computed

When looking at EXCLUDED in the test suite for observable collections, maybe __hash__ needs to be implemented as a reader too? I'm not entirely sure.

The other attributes don't need to be wrapped, __hash__ is the only questionable item in the list.

Would be nice to have a benchmark setup so that we can make informed decisions on performance.

We could leverage pytest-benchmark together with github-action-benchmark.
And naturally we would need to have some proper functions to run as benchmark.

E.g. dict.copy causes depend to be called for the dict dep and all its keydeps, where only the dict dep would be sufficient.

This mostly matters in eager mode but in general it would shave off some redundant function calls

Update README.md to state that there is one dependency for the use of the store.

from observ import computed, observe, watch


doc_state = observe({"selected": False, "pos": (0, 0)})

def my_callback(old, new):
    print(old, new)

w = watch(lambda: doc_state["selected"], callback=my_callback)

doc_state["selected"] = True
doc_state["selected"] = False

For example, in the code above, is it possible to watch both the selected and pos var without declaring a new watch statement?

I guess I am trying to understand how multiple variables can be watched. My understanding is that something like the following is needed:

from observ import computed, observe, watch


doc_state = observe({"selected": False, "pos": (0, 0)})

def my_selected_callback(old, new):
    print("selected: ", old, new)

def my_pos_callback(old, new):
    print("pos: ", old, new)

# setup the watchers
w1 = watch(lambda: doc_state["selected"], callback=my_selected_callback)
w2 = watch(lambda: doc_state["pos"], callback=my_pos_callback)

# do some stuff...

# set the sate
doc_state["selected"] = True
doc_state["selected"] = False

doc_state["pos"] = (3, 5)

Should they be buffered? Should I provide event loop integration for various libs (i.e. asyncio, qt, etc)?

Currently we only test on python 3.6 locally, would like to use CI to test on multiple python versions

Not sure if this is really worthwhile, there's a performance tradeoff I guess. It depends if the dependency tracking is more expensive or if the computed prop function is more expensive.

It's probably the latter, so that would make the resolution of this issue worthwhile.

Will have to see how I can generalize the equality test over all the WRITER and KEYWRITER methods we wrap.