@thomashoneyman reported on Jira:

I'm attempting to mount components (with their scoped CSS) directly into HTML that has an external stylesheet. Some of our styles now clash, like our resets specific to UI kit.

Expected behavior: I can include cn-tailwind.scoped.css in the Select documentation without it affecting any of the page styles. I can then build a typeahead using the Ocelot styles (working around the parent CSS needed).

Note: If this doesn't seem worth the effort we could just include a small custom stylesheet to write styles for the few example components we need.

I was wondering whether this would be desired and how much support would be provided for working on it.

I've already been working on this somewhat here: https://github.com/JordanMartinez/purescript-ocelot/tree/halogen5-update

I'm currently using Spago so that development is easier, but I imagine we'd need to get some dependencies to publish a new version so we can refer to them via bower.

Environment

• PureScript 0.12.0
• Halogen ^4.0.0
• Ocelot 0.10.2

Current behavior

Typeahead component raises SelectionChanged message whenever the selected item is modified, regardless of what or how that was triggered, and without any way for the parent to know. This can result in an inability for the parent to reason about what to do.

Consider this scenario: a used car inventory page that lets you filter by make and model. Both make and model typeaheads have handlers that update the inventory results when the user makes or clears a selection. However, the make typeahead's handler will also need to reset the model typeahead, as those models will no longer be valid. Here's where we run into a problem: imagine the user has selected the make "VW" and the model "Jetta", then they decide to switch the make to "Toyota". This triggers the handler for the make to fetch new results, but also clear out the model selection from the invalid options and "Jetta" selection. But clearing the "Jetta" is a selection change, so this will trigger the handler to unnecessarily fetch new results.

This is a simplified example, and can actually get a lot uglier. Especially when you introduce multiple sources of truth (i.e. query params + component state).

Desired behavior

If the SelectionChanged message had some way of telling the parent what triggered the selection change, the parent could make better decisions on how to react. E.g., only fetch new results when the item was changed by the user, or when it wasn't triggered from the Reset query.

This is really nice!

I have to ask because this breaks some scripts I run.

> bower info purescript-ocelot
bower ENOTFOUND     Package purescript-ocelot not found

Please try to register this and publish it on Bower, so that I have less maintenance work in the future.

Since https://citizennet.github.io/purescript-ocelot/dist/ works but the link is https://citizennet.github.io/purescript-ocelot/

I would change this line here:

to cp -r dist ../gh-pages/

we can use https://github.com/milesfrain/halogen/blob/tailwind/css/tailwind_inputs.css (which I found here) to generate classes

Environment

• Ocelot [v0.14.5]

Current behavior

Currently you can set the initial items for a dropdown or typeahead via either the parent's render function, or the parent's eval by sending the child component the appropriate query. However, the only way to update the items for a dropdown or typeahead is from the parent eval via a child query.

Expected behavior

There are two scenarios for managing the items for a component:

1. letting the child fully manage them

In this scenario, the parent fetches the items once and passes them to the child, or provides the child a function for fetching them itself—as with an async typeahead. In this scenario, the parent needn't ever hold on to the items in its own state. This scenario is currently supported by Ocelot.

2. the parent manages the items

In this scenario, the parent has reason to deal with the items and hold onto them in state, and the child should be able to basically use the items that are managed on the parent state. This scenario is only partially supported, and requires manually updating the child's items.

Currently, the items on the parent's state can be passed to a dropdown like so:

HH.slot unit Dropdown.componont
  { items: state.items
  , selectedItem: state.selectedItem
  , render: renderDropdown
  }

But then when state.items changes, the dropdown component won't be notified. If we update the typeahead and dropdown components with a receiver, we can respond to changes in input from the parent.