Bug 940510 - Initial draft of signals JEP.

[Gozala]

No description provided.

[jsantell]

I think I understand lift, but I don't understand this example

[jsantell]

nm, I think I do -- does this also update the value of Y when X is updated, or is it evaluated lazily?

[Gozala]

I think I understand lift, but I don't understand this example
nm, I think I do -- does this also update the value of Y when X is updated, or is it evaluated lazily?

Yes Y is updated every time X is updated, but also yes on laziness. Neither Y or X will get updated unless they are consumed, in other words there should be write(..., Y) somewhere or write(..., Z) where Z is derived from Y.

Note: Above being said Z also could be derived from X instead, in such case Y won't be updated unless Y or some other W (which is it's derived signal) is written.

I go into details of this later in the document, but if it's still not clear, we should find a way to make it so.

[jsantell]

I don't quite understand implementation-wise, how to do things like creating a signal, ending a signal, reading/unwrapping from a signal

[erikvold]

would this not be // XY x: --x1-y1---x2--y2----x3-y3-- based on what was said before "biased towards the first signal if both signals update at the same time" ?

[erikvold]

I guess the bias is that the x3 value is the last/current value.

[Gozala]

would this not be // XY x: --x1-y1---x2--y2----x3-y3-- based on what was said before "biased towards the first signal if both signals
update at the same time" ?

Yes you right it should be x3 y3

[erikvold]

Hey @Gozala it looks really good! I'd like to see some examples on how to end a signal though. Also I'm not sure I like the write/writer, is there not some way that updateMenuItems could be called directly and avoid the write/writer step. Like write(updateMenuItems, signal) ? and rename write to process (which you suggested in irc) ?

[jsantell]

Agree with Erik -- looks good, but this is just from a consuming perspective -- it's not clear how to create, modify or end signals if we were to create a signal-based module

[Gozala]

So I talked over with Evan and got blessing from him too, we also discussed write API and he suggested something like:

const reactor = new Reactor({
  onStart: () => {},
  onEnd: () => {},
  onNext: () => {},
})
reactor.run(input);

thoughts ?

[Gozala]

Another alternative could be something something more high level:

Assuming that MenuItems is a signal that starts & ends with empty hash and
on updates is like:

{ "sdk-menu-item-1": { id: "sdk-menu-item-1", label: "foo", owners: ["window-id-1", "window-id-2"],
  "sdk-menu-item-2": { id: "sdk-menu-item-2", label: "foo", owners: ["window-id-1", "window-id-2"],
  ....
 }

One should be able to define MenuItem class as follows:

const MenuItem = Model({
   // Called any time new value added to a hash
   setup: () => {},
   // Called each time value disappears form hash
   dispose: () => {},
   // Called each value in hash changes
   update: () => {},
   // ....
}, MenuItems);

[Gozala]

I guess owners could be actual set of windows instead of window IDs.

[Gozala]

I think @jsantell suggested something like this instead:

const MenuItem = Class({
   extends: Reactor,
   // input signal (I hate name `react`)
   react: MenuItems,
   // Called any time new value added to a hash
   setup: () => {},
   // Called each time value disappears form hash
   dispose: () => {},
   // Called each value in hash changes
   update: () => {},
   // ....
});

[Gozala]

I guess I would prefer something like:

const MenuItem = Class({
   // Called any time new value added to a hash
   setup: () => {},
   // Called each time value disappears form hash
   dispose: () => {},
   // Called each value in hash changes
   update: () => {},
   // ....
});

Reactor.run(MenuItem, input);

[Gozala]

@jsantell @erikvold I have updated some parts to reflect received feedback. To be specific I rewrote section about laziness and changed most of it to be oriented around how to define a signal. I have also rewrote part about consuming signals in order to replace write that no one liked with Reactor({ ... }) that @jsantell agreed was more
clear.