jcouyang
display-once semantics intended?
I've noticed that an Owlet graphical component is only rendered in one location at a time. See here for example: https://scalafiddle.io/sf/QqYTclD/1 Is that the intended semantics?
I'm asking because this actually somewhat relates to our discussion in the other #5 issue. In particular, it would be very nice if two copies of the same component could be rendered and the user be guaranteed that they will "stay in sync."
In other words, let's say that there is a number val myNumber = int("mynum",1) the value of which is utilized by various other components in various other parts of the display. The way Owlet seems to currently work right now, the gui component that allows the user to change the myNumber value is only rendered one place. However, in my opinion, a preferred semantics would be to allow it to be rendered in multiple places but guarantee that the two renderings will always stay in sync.
I hope what I'm talking about is making sense?
I'm having a hard time finding where in the code it enforces this display-once semantics. For example,
val myString = string("mystring,"")
val myString2 = myString
val both = myString &> mystring2
render(both,..)
This will only will render the myString component once which means that (rightfully so) it treats myString2 as identical to myString and therefore seems to ignore one of them?
In other words, it seems that myString &> myString2 is equivalent to myString &> myString and that therefore the &> operation is idempotent?
Yes it is intended.
An Owlet is actually a bifunctor, but you can only map on the right value(signal), left (node) map is always identity, so the actual value of node never change no matter how many times you map it.
The other way of thinking is imagine using spreadsheet
You create an input in a1 cell and than create an a2, it's value is fx=a1
In the spreadsheet you only got one input box a1, a2 is output fx cell not input
Not sure if it make sense to you?
Yes, it makes sense now that you mention that Owlet (at least how it is currently implemented) is a bifunctor. However, let's think about this for a bit:
output(a) &> output(a) behave as expected in the sense that the Owlet a is displayed twice. My argument is that there should be a similar notion of, for example, input(a) &> input(a) where the ability to change value associated with Owlet a is available at two places on the page. Of course to prevent errors/race-conditions and such, the user should only be able to ever actually interact with one of the inputs at a time (e.g. if the user interacts with the first one, then the 2nd one is perhaps "disabled" or maybe (temporarily) switches its rendering to something more akin to output(a) until the user has finished interacting with the input.
In other words if we could come up with a clever way to add a function input(..) then we can still preserve the semantics of the spreadsheet model like you are envisioning while opening up the possibility of the value being "editable" in more than one location (for example, across a network boundary!?). The library would hide the complexities around the race conditions associated with the user editing the value in more than one place (e.g. it would ensure that only the most recent edit "wins" in the case of a synchronous local computation, or uses some other consensus mechanism in the case of an asynchronous one across a network boundary or something -- details on this front could actually be pluggable I think).
I hope the intuition as to why this would be useful is beginning to come across? If not, I'll try to come up with a more concrete example.
Bottom line: spreadsheet programming where all the components are on the same page is neat, but spreadsheet programming where (some of) the components are spread out across the network/internet (if possible) is "really neat" to think about :-)