@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