WIP: Demo app with online theming tool

[ben-girardet]

[bigopon]

Nice work 👍 . Ther are 2 things that I would want to request are: better checkbox/radio behavior with names and less jumpy behavior, like this:

Those 2 small details would greatly improve the first impression, at least I hope so.

[ben-girardet]

Thanks for your first feedbacks @bigopon

You speak about 2 things, did you mention both in your previous comment ?

At the moment I have focused mainly in the « online theming tool ». At the bottom of this page there is the showcase. How do you feel the checkboxes and radios in this showcase ?

Next I plan to review all the components page and improve the first impression look.

Once I’ve finished the first stage of improvements I would like to call for more reviews so that we can significantly improve the first impression.

[bigopon]

@ben-girardet yes. the first one is the ability to use label for checkbox the 2nd one is the jumpy behavior described by the gif. Sorry for the confusion.

[ben-girardet]

@bigopon I ping you here as I have updated the demo with your feedbacks. Please have a look here: https://ux.mintello.com/#/aurelia and look at the showcase part (not the specific component parts that I will update later on).

Also feel free to give feedbacks on the Online Tool page that is ready from my part.

[ben-girardet]

@bigopon @EisenbergEffect @serifine

I ping you all here for a question about the grid component. Could you please have a look at this commit . Here is my commit body:

The previous behavior was to determine the size (xs, sm, md, lg, xl) based on the window width. This is fine when the grid is placed in full width but doesn't work well when it's placed inside an already constraint element.

This commit suggests to change this behavior and base the grid reparation on the actual grid element width.

Would you agree with this change ?

[bigopon]

@ben-girardet I think the proposed change related to grid size based on container is good. The characteristic of material, feels to me, is quite spacious in for all bits and pieces, for that, I think grid will ever have good display on too small. Though there's situation that it can be considered big enough, we need the size observation. I'd suggest ResizeObserver and a note for polyfilling this dependency for our users

[ben-girardet]

@bigopon I've pushed a fix using ResizeObserver

However, as this feature is not available for safari, I think it's better to include the polypill straight in the package. What do you think ?

[bigopon]

@ben-girardet I think it's reasonable to require a global API available for ResizeObserver. I did similar thing for Virtual Repeat custom attribute, as you can see here https://github.com/aurelia/ui-virtualization/blob/master/src/virtual-repeat.ts#L906

We can offer additional configuration, for when people use ux: ability to configure ResizeObserver implementation:

aurelia.use.plugin('@aurelia-ux/core', { resizeObserverImpl: myResizeObserverPolyfills })

cc @EisenbergEffect @fkleuver @MaximBalaganskiy

[ben-girardet]

Hum...

We could also provide a fallback with a PropertyObserver on element.offsetWidth if no implementation of ResizeObserver is found in global.

It would only cost a few lines of code and make the lib works correctly. In this case I suggest to send a warn on console stating that we recommend polyfilling ResizeObserver.

[bigopon]

The issue with observing element.offsetWidth is that it uses dirty checking, since there's no known way to observe it. We can also use the relative + absolute dummy div + iframe for resize event, but I think it has its own limitation and is not as good as ResizeObserver, or even the polyfill of ResizeObserver

[bigopon]

Here's a custom implementation that auto detect ResizeObserver API support, and then uses it, otherwise fallback to configurable dirty checking https://gist.dumber.app/?gist=a51a80be7dc589c6ad8feeae6853afda We can use this as an internal custom attribute for the grid. So it would only dirty checking with much lower rate than our built-in dirty checker (160ms vs 120ms)

[ben-girardet]

Really cool.

To be honest I was not aware that @computedFrom('element.offsetWidth') was using dirty checking. I need to better understand which cases have proper observers and which cases require dirty checking. Is there a way to detect in an application where dirty checking is in use ?

I'll go ahead and implement your custom implementation.

[bigopon]

Hmm, there's no alert like that at the moment. Generally, anything that cannot be communicated via an event will be dirty checked.

[ben-girardet]

Once #255 will be merged I'm planning to continue here and experiment with a <drawer-container/> component that would host a drawer and side content.

My goal would be to offer an easy way to use drawer in persistent mode for desktop and modal for mobile as recommended by material design. Pretty useful for navigation for exemple.

I'm hoping to be able to do something like:

<ux-drawer-container>
  <ux-drawer left>
    <!-- drawer content -->
  </ux-drawer>
  <!-- content that should sit next to the drawer -->
</ux-drawer-container>

The drawer container would have a mobileBreakpoint bindable to determine from which window width (or container width) it should break to mobile display. If not mobile, then the drawer reduce the space left for the content.

Does it make sense ?

[bigopon]

@ben-girardet thanks for the plan. That sounds great to me.