jcouyang / owlet

Typed Spreadsheet UI library for ScalaJS
https://oyanglul.us/owlet/
40 stars 5 forks source link

default gui function for Either and Pair? #5

Open cryptokoans opened 5 years ago

cryptokoans commented 5 years ago

In a similar way that graphical checkbox can be thought of a simple presentation of an Owlet[Boolean], I've been wondering if we might be able to make a generic Owlet[Either[A,B]] perhaps called "choice" or "fork" or something? It would be a default presentation of the user essentially choosing an execution path I think?

Or, perhaps a slightly more concrete example might be a classical spreadsheet where each cell is Either[RawValue,Formula] ?

jcouyang commented 5 years ago

Boolean works because whether tick or untick the box it emit the same type. I'm not sure what Owlet[Either[A, B]] can be represented in the sense of web component? What kind of component can emit either A or B type of value?

in my mind RawValue and Formula are both model as Owlet[A], one without computation one with computation, but both emit A

cryptokoans commented 5 years ago

Right, I see what you mean regarding checkbox, and perhaps my example was not the best. A better example might be one pertaining to some form of error handling where type A represents an error and type B represents the expected value?

Additionally, one way to think about Boolean is as a sum type which means that the checkbox component (at least in theory?) is a special case of Owlet[Either[_,_]]

Anyway, the intuition behind coming up with some representation for Either, Pair, and maybe even Function1 is that it would open the door to making a very neat way to allow end-users (e.g. not us scala programmers, but the users that are actually using the programs/sites we write) to program on top of Owlet?

cryptokoans commented 5 years ago

I've been thinking more about this, and it seems that perhaps that best example of a component that can emit either an A or B is actually the error propagation case. This is actually really interesting. Specifically, if an end user is dissatisfied with how a component is behaving, they can essentially "file a bug" and the report would sort of start propagating backwards. It's sort of like a user-generated exception and bug reporting all rolled into one.

Not sure if the above makes much sense or not but figured I'd at least try to explain one reason why such a component would be interesting :-)

jcouyang commented 5 years ago

If i understand correctly, for user error, you can always map over an owlet and covert it to either E.g. if you consider numbers less than 0 is error

int("a", 0).map(a=>if(a<0) Left("error") else Right(a))
jcouyang commented 5 years ago

currently the design of owler DOM is just to map web components to owlet components

cryptokoans commented 5 years ago

currently the design of owler DOM is just to map web components to owlet components

Yeah, that makes sense. It could be that what I'm attempting is too far out of scope. I'll likely still keep thinking about it though :-)