Question: different approach to TraversalP, LensP etc.

[paf31]

First of all, thank you for writing this library, it is really excellent.

I was experimenting with zoomOne and zoomAll, and was trying to come up with a slightly different, more uniform approach. The idea is that if we can express the UI type as s -> f s for some Applicativef`, then you get lifting over all optics "for free". I came up with this:

newtype Markup a = Markup (Array (HTML a))

instance functorMarkup :: Functor Markup where ...

instance alternativeMarkup :: Alternative Markup where ...

newtype UI state = UI (state -> NonEmpty Markup state)

Then the core combinators become trivial:

lens :: forall a b. LensP a b -> UI b -> UI a
lens l (UI ui) = UI (l ui)

traverse :: forall a b. TraversalP a b -> UI b -> UI a
traverse t (UI ui) = UI (t ui)

The key is the NonEmpty applicative functor which captures something like Halogen's mergeWith combinator, combining components in parallel, keeping the latest state from each:

data NonEmpty f state = NonEmpty state (f state)

instance functorNonEmpty :: (Functor f) => Functor (NonEmpty f) where
  map f (NonEmpty state fa) = NonEmpty (f state) (map f fa)

instance applyNonEmpty :: (Alt f) => Apply (NonEmpty f) where
  apply (NonEmpty f fs) (NonEmpty x xs) = NonEmpty (f x) (map ($ x) fs <|> map f xs)

instance applicativeNonEmpty :: (Alternative f) => Applicative (NonEmpty f) where
  pure a = NonEmpty a empty

I think this could generalize nicely in a few ways:

• We can use other Applicatives instead of just Markup, including Aff, Producer, etc.
• We can use Eff inside UI to support third-party widgets.

Right now, I think this library has the best story for component composition I've seen in a PureScript library, but it would be really great to be able to handle third-party components and things like AJAX too.

I know this is a fairly big change, but would you take a PR?

Thanks

[zrho]

That sounds quite interesting indeed. As soon as I come back from vacation
(September 2nd) I will have a more thorough look at it. If it works out, I
will be happy to accept the PR.

Btw, lifting Eff into the UI is already possible, though there is not yet a
function for lifting.
Am 29.08.2015 18:25 schrieb "Phil Freeman" notifications@github.com:

First of all, thank you for writing this library, it is really excellent.

I was experimenting with zoomOne and zoomAll, and was trying to come up
with a slightly different, more uniform approach. The idea is that if we
can express the UI type as s -> f s for some Applicativef`, then you get
lifting over all optics "for free". I came up with this:

newtype Markup a = Markup (Array (HTML a))
instance functorMarkup :: Functor Markup where ...
instance alternativeMarkup :: Alternative Markup where ...
newtype UI state = UI (state -> NonEmpty Markup state)

Then the core combinators become trivial:

lens :: forall a b. LensP a b -> UI b -> UI a
lens l (UI ui) = UI (l ui)
traverse :: forall a b. TraversalP a b -> UI b -> UI a
traverse t (UI ui) = UI (t ui)

The key is the NonEmpty applicative functor which captures something like
Halogen's mergeWith combinator, combining components in parallel, keeping
the latest state from each:

data NonEmpty f state = NonEmpty state (f state)
instance functorNonEmpty :: (Functor f) => Functor (NonEmpty f) where
map f (NonEmpty state fa) = NonEmpty (f state) (map f fa)
instance applyNonEmpty :: (Alt f) => Apply (NonEmpty f) where
apply (NonEmpty f fs) (NonEmpty x xs) = NonEmpty (f x) (map ($ x) fs <|> map f xs)
instance applicativeNonEmpty :: (Alternative f) => Applicative (NonEmpty f) where
pure a = NonEmpty a empty

I think this could generalize nicely in a few ways:

• We can use other Applicatives instead of just Markup, including Aff,
  Producer, etc.
• We can use Eff inside UI to support third-party widgets.

Right now, I think this library has the best story for component
composition I've seen in a PureScript library, but it would be really great
to be able to handle third-party components and things like AJAX too.

I know this is a fairly big change, but would you take a PR?

Thanks

—
Reply to this email directly or view it on GitHub
#4.

[paf31]

One other small observation: if we generalize s -> f s to s -> f t, then the lens operations will still work, but we can separate the state and "action" types. Then a function s -> t -> s (is that a Setter?) can be composed on the right to get back to this original formulation.

[paf31]

I spent some time on this, but ran into some issues:

• The Monoid instance that you end up wanting for UI is not obvious. Generally, having to keep the
• Lack of indexed traversals become a real problem.
• In the todo example, you have handlers for higher level components passed down to child components, which makes sense, but which my approach doesn't deal with.

I'll keep looking into whether or not this approach is feasible.

[paf31]

I did a bit more work on this, but using profunctor lenses. I worked in a separate repo, because code got very different, but it might be worth having a look at anyway.

https://github.com/paf31/purescript-sym/blob/master/src/SYM.purs

[paf31]

I feel like I'm getting close enough to feature parity that it would make sense to start thinking about making a PR again. I've learned the following things so far:

• Profunctor lenses allow you to avoid roundtrips via things like Pretext and Bazaar which is nice.
• Profunctor lenses also permit applying lenses/prisms/traversals to components just like functions: stringLens textBox gives a textBox for the stringLens field, for example, which is nice in practice.
• Traversal is tricky, and I work around it by moving back to an Applicative representation of Traversal, which works nicely (I think).
• IndexedTraversal remains a problem, but it's possible to hack around it without too much trouble.

I still need to show that things like AJAX are possible, and demonstrate integration with 3rd party components, but it's not far off.

Also, sym uses React, since it was easier to prototype that way, but I think it would be nice to support both React and virtual-dom backends.

What do you think?

[zrho]

I think this is a great direction for the library to go.

The monad instance of UI, as we have it now, doesn't really seem to be particularily useful if you have views that admit a monoid instance; hence all the WriterT stuff currently. In order to allow for multiple backends, we could parameterize the UI profunctor over an arbitrary view type and give it a monoid instance if the view type has one. In addition to that, a censor- or withHTML-like function for nested elements or non-monoid views and we have recovered the view part. There is also the choice of effects or monad for integrating third-party components or AJAX. With something like

newtype UI eff v s t = UI (s -> (t -> Eff eff Unit) -> ExceptT (Eff eff Unit) (Eff eff) v)

we should be able to recover all the current functionality, with a much cleaner interface.

[zrho]

I uploaded my experiments at 9912b7e, with a bit of integration. The todo example already works, the ajax example does not due to the lack of lifecycle features currently. What do you think?

[paf31]

Nice! I'm glad it fit so well together 😄

Some comments from a quick look over the code:

• I was never sure about the name Sink. It originally meant something else, but now it seems like a bad name. I suppose it's quite a bit like Bazaar in a sense, but maybe we could come up with a better name.
• I'm glad you were able to generalize foreach to Traversable. I had a stab at this but couldn't quite work it out.
• Keeping the Monoid separate and using withView to change the type looks like it works nicely. I'll have a think how I might convert sym into a React backend for OpticUI now.
• Depending on both optics and profunctor-lenses might be less than ideal. Maybe we could roundtrip Lens and Prism applications via Sink too, although then it loses the nice composition syntax. Or maybe profunctor-lenses just needs to be brought to feature parity with optics.

My opinion is that while you've lost AJAX, this is a net improvement overall, and perhaps a pleasant API for AJAX could be constructed using Handler?

To me, the four main pain points in a UI library seem to be (after working on Halogen 0.4):

• Composition of components
• Supporting other patterns like MVI (i.e. separating "inputs" from state a la Halogen or Elm architecture)
• Handling asynchronous effects neatly
• Integrating with 3rd party components

So, the first is solved (as I've said before, I think this library has the most elegant composition story that I've seen), and I think optics give a very nice solution for the second as well, but I think this puts OpticUI in a nice position to solve the remaining two.

[paf31]

For AJAX, one simple approach might be a primitive like:

withCallback :: forall eff a. Handler eff a -> ((a -> Eff eff Unit) -> Eff eff Unit) -> Handler eff Unit

used like

onClick $ handler `withCallback` \k -> makeRequest "http://purescript.org" k

Edit: one more thing - I think keeping Handler abstract, and hiding the constructor, might be a good thing.

[FrigoEU]

The profunctor way is amazing! It took me some time to get how it works, but it's amazingly elegant.

I have some time available and I'd really like to contribute to this library. Looking at paf31's post above, I feel "integrating with 3rd part components" is a place where I could get started. From my own experience, integrating with them mostly comes down to adding some hooks that are run when initializing, finalizing, and sometimes updating components.

Do you see this as the way to go for Optic UI as well? If yes, I'll take a look around at how Halogen and Thermite implement it and take a stab. Something along these lines:

initialize :: forall eff. (HTMLElement -> Eff eff Unit) -> Props
finalize :: forall eff. (HTMLElement -> Eff eff Unit) -> Props

AJAX also seems interesting, although I don't know immediately how to start implementing that one.

[paf31]

I really like the idea of parameterizing UI over some monoidal view type, which should allow us to support various backends, like React/Thermite, virtual-dom/Halogen and now possibly incremental-dom as well. The abstraction is very general and could probably stretch as far as something like a command line UI or React Native.

One other thing I really like about OpticUI is how (aside from the lens dependency), it is very low-level and unopinionated, using simple things like Eff for handlers, and not imposing any choice of abstraction on the user.

Hopefully, extracting a minimal core library would allow things like initializers and finalizers to be implemented in other libraries for suitable backends.

[FrigoEU]

Optic UI with Reactive Native would be totally awesome!

I thought initializers and finalizers would be easy, but it's more challenging than I thought. I have a simple implementation:

exports.onInitializedP = function (f) {
  var Hook = function () {};
  Hook.prototype.hook = function (node) {
     f(node)();
   };
  return new Hook(f);
};

exports.onFinalizedP = function (f) {
  var Hook = function () {};
  Hook.prototype.unhook = function (node) {
    f(node)();
  };
  return new Hook(f);
};

onInitialized :: forall eff. (HTMLElement -> Eff eff Unit) -> Prop
onInitialized f = prop "opticui-initialize" $ onInitializedP f

foreign import onInitializedP :: forall eff. (HTMLElement -> Eff eff Unit) -> Prop

onFinalized :: forall eff. (HTMLElement -> Eff eff Unit) -> Prop
onFinalized f = prop "opticui-finalize" $ onFinalizedP f

foreign import onFinalizedP :: forall eff. (HTMLElement -> Eff eff Unit) -> Prop

The problem with this is that you can only use this like this:

init = H.onInitialized (\e -> setClassName "init" (htmlElementToElement e))
fin = H.onFinalized (\e -> setClassName "fin" (htmlElementToElement e))
H.button [ init, fin ] (text "X")

And not inline like this:

H.button [ H.onInitialized (\e -> setClassName "init" (htmlElementToElement e)) ] (text "X")

Reason is that we're making a new function on each pass, virtual dom compares these functions with ===, decides they're not the same, and rerenders the whole node.

Halogen solves this by keeping some kind of data structure around that keeps the previous initializers/finalizers. I haven't looked at the solution there in detail though. Is that the only way to do it? Anyone has another idea?

[zrho]

I do not know horribly much about the inner workings of virtual-dom, but I think there is a way to bypass automatic checking for updates and use some hash code like thing that is compared instead. Maybe that would be interesting for some third-party components, especially if they manage their DOM on their own (e.g. when injecting React components). In some other cases, where you do want virtual-dom to manage the view, but on the same time want to use initializers and finalizers, that is not really an option.

With regards to storing the previous initializers and finalizers, this leads to a problem I experienced with async computations, delay components and etc.: while it is easy to store "technical" data like a reference to a handler, previous initializers, timestamps in animations etc. in the managed state of a UI component, routing that state becomes annoying quite quickly and the type signature of the component leaks the "technical" state in addition to merely the "logical" - read visible - state of the UI.

Thus it might be useful to think about options to store the technical state somewhere different, but I haven't found a way yet to do that without encountering the same kind of problems that caused me to work on optic UI instead with react, e.g. components suddenly forgetting or magically remembering state that doesn't belong to them.

And, yes, React Native support would be incredible. I would be glad to split out the virtual-dom and HTML generating parts into an extra library to leave a minimal core after we found a solution to the state problem, since there might be some interesting interactions with the backend required to solve it.