@niwinz: hey! I started reading the UXbox code, cool stuff 👍, were there any particular things that served as inspiration for the event abstractions?

hmm no, some ideas from elm

thanks!

many ideas are own,

the WatchEvent is a clever idea and it's also nice that events can be Update+Watch in one because they're just protocols

yes, and the order always is

Update > Watch > Effect

so watch will receive the state already updated by the update

and watch receives the main stream so it can react to posterior events for cancel/abort stuff

tipical case for autocomplete backed by backend that allows cancel xhr requests if the user writes quickly

> and watch receives the main stream so it can react to posterior events for cancel/abort stuff I'm not sure I understand. Are WatchEvents cancelable? how? (maybe there's an example in the code?)

https://github.com/uxbox/uxbox/blob/master/src/uxbox/main/data/history.cljs#L112

maybe it can serve as example

the basic is, in watch event you trigger some async stuff and in same time subscribe to main stream for watch if more events of same type are emited by the ui

so you can react old requests and leave only the most recent continue

in an hipotetical use case

ah ok, I see, saw the stoper thing before but didn't fully understand it's utility.

any reason you don't use positional record constructors?

I don't like its syntax

is just esthetic preference

about the other topic, maybe is not clear the purpose on simple view but is very very useful

for implement things like autocomplete backed by server returned results

you should be able cancel old requests in order to proceed with news ones on the user input...

and this allows do that