These are chat archives for ractivejs/ractive

4th
Jun 2017
Joseph
@fskreuz
Jun 04 2017 00:04

Data and event management pages have been simplified and now contains moar examples :tada:

Lemme know if there's something that needs fixing (I bet there's a lot of typos and grammatical errors in there). :smile:

Chris Reeves
@evs-chris
Jun 04 2017 00:15
:tada:
Chris Reeves
@evs-chris
Jun 04 2017 05:15
question before I open a PR: should set operations resolve with the value (or list of values) that is set? (part of #2983)
it makes sense to me for single values, but setting multiple values at the same time gets kinda weird
the point of the whole thing being that if you set a promise, the set promise wouldn't resolve until both transition complete and value promise resolution
for multiple values, it would use Promise.all when waiting
and the current transition-only promise could be exposed as a property of the returned promise
Chris Reeves
@evs-chris
Jun 04 2017 05:20
or... I've exposed the Ractive constructor on Ractive and any extensions, so the promise adaptor (or whatever) could do monkey patching on set without a hard dependency on ractive
that's only on edge right now, but it could easily be cherrypicked to 0.9
to be clear, that's Ractive.Ractive === Ractive && Ractive.extend().Ractive === Ractive
Joseph
@fskreuz
Jun 04 2017 14:08
I lean towards this being an implementation detail of the promise adaptor.
If this was implemented on set, how would it work when setting a map?
Also, it won't be long before this feature gets requested for the other setter methods that return a promise, like shift, push, animate, add, etc. which isn't covered by the adaptor and we don't have an implementation to compare with.
I think the only problem is trying to defer the resolution to the promise unpacking instead of the initial set, a responsibility of the adaptor. Assuming the promise is timed right, the value can be retrieved like so:
ractive.set('foo', promise).then(() => {
  const value = ractive.get('foo')
});
Joseph
@fskreuz
Jun 04 2017 14:23
More brain dump: If the value set was a promise, a promise isn't an animateable value. The transition shouldn't even run at all. It should run after the promise unpacks its value.
(my 2c before any form of coffee was consumed)
Juan C. Andreu
@andreujuanc
Jun 04 2017 14:26
I think promises are very mainstream. Is the promise adaptor coming on by default?
Chris Reeves
@evs-chris
Jun 04 2017 14:26
but if having a value of some sort causes a conditional to render (out intended), then there may be transitions associated with nodes downstream from the conditional
no, you have to add it
there are actually two of the different ones that have slightly different behaviors
two or three
Joseph
@fskreuz
Jun 04 2017 14:28
:scream: I only saw one of them. The one which only did a basic unpack and set.
Juan C. Andreu
@andreujuanc
Jun 04 2017 14:29
Do those different behaviors may interfere on what and how the set returns value?
I think there should be an "official" one xP
I do lots of
dataService.MyTable.where(<condition>).read((x)=> { ractive.set(x); })
So was thinking on getting the adaptor.
Chris Reeves
@evs-chris
Jun 04 2017 14:31
FWIW await .some.promise in template is on my list of nice features to have, but I haven't come up with a good way to do it
I think this the most popular promise adaptor
Juan C. Andreu
@andreujuanc
Jun 04 2017 14:35
await in template?? :surfer:
Chris Reeves
@evs-chris
Jun 04 2017 14:36
yep
Juan C. Andreu
@andreujuanc
Jun 04 2017 14:36
Why?
My simple mind can't imagine that!
That'd take some "logic" to the template.
Chris Reeves
@evs-chris
Jun 04 2017 14:37
it wouldn't actually be await, but something to allow a promise to resolve to use the actual value rather than the promise itself
Juan C. Andreu
@andreujuanc
Jun 04 2017 14:37
i see
for v1.1 ? :P
Chris Reeves
@evs-chris
Jun 04 2017 14:38
2.0 😁
Juan C. Andreu
@andreujuanc
Jun 04 2017 14:38
xP
Chris Reeves
@evs-chris
Jun 04 2017 14:39
thinking about it, an await mustache block may make more sense
but then we're back to 'is built in promise support worth the extra weight?'
it probably is best as an adaptor
just need to make a more modern version
and fix the adaptor API 😉
Juan C. Andreu
@andreujuanc
Jun 04 2017 14:57
C:
Chris Reeves
@evs-chris
Jun 04 2017 20:41
for the first time since 2012, we're down to a single page of issues (on the github desktop layout)
Joseph
@fskreuz
Jun 04 2017 20:42
:tada: