pstjvn / pstj-closure Goto Github PK

Material button should incorporate the logic related to icons and fab should reuse it instead of implementing its own version.

Why will you use delete in stead of setting null in ScrollArea according to Google JS guide line?

Currently the render and decorate paths are mixed in the implementation which prevents real decoration of static (server generated) HTML.

When using decoration pattern and all radio buttons are also decorated and the selected one is set via the 'value' parameter on the group but is not set on the decorated child the selected child is not reflected in the component which leads to the ability to select more than one option at a time (the first time).

The color arc should not extract the image data, instead it should delegate this as it is use case specific.

When resetting the value of an input and it is marked as 'required' the invalid state is enabled and
this way when a form is being reset (input value set to empty string) all inputs are marked as 'error' which confuses the user. Resetting the value to empty string programmatically should not set the invalid state.

Currently the pattern is used as a stand alone 'plug' for element creation. Instead an unified patern should be used for consistency and simpler usage.

https://github.com/pstjvn/pstj-closure/blob/master/ui/controls/controlrenderer.js#L88 uses a deprecated API.

Should review the code and decide if we want to support it any longer.

The current implementation of the drawer panel uses deprecated design and cannot be used to generate UI from JSON configuration.

Currently ripple effects are triggered for items in containers that allow for scrolling. This sends mixed signals to the user, the ripple should only be triggered when there is no scrolling or should be at least canceled when scrolling starts.

The material design related code is missing proper documentation on lot of places and is missing author information.

Currently the Icon class creates a synthetic event to notify the icon container that an animation has been completed, investigate the possibility to skip the creation of the custom event and reuse the browser's ANIMATIONEND event.

Recent changes remove the support for greyscaling the arc.

It should be added back.

Most pstj components, such as HeaderPanel supports declarative construction of UI via HTML elements. But the root element, DrawerPanel does not support decoration pattern.

Should my app be construct all UI by code? Is there suggested pattern?

Implement a simple, proof of concept model + control for single direction flow (action->model->view pattern).

Currently the declination of the arc from 12 o'clock is static (hard coded). It should instead be dynamic/configurable by parameters.

The preventDefault call on android prevents the focus of the input while not preventing it triggers the action on other components (like checkbox) twice.

Related to the ripple pattern is the revealing pattern as observed in this demo:
https://plus.google.com/+PeterStJ/posts/EsCoWBxmBmV?pid=6071442900437206962&oid=115048444253276449361

Needs implementation for this.

Strategy: investigate the possibility to re-use the goog.fx utilities for this (and possibly orchestrate the 'hero' type of animations).

Currently the SVG icons are static templates, which bears no benefits other than being able to filter them out on compilation. This benefit however is dwarfed by the amount of work needed to provide the svg code and the renderer that can understand the modes the icon can be in.

Alternatives:

1. use a text file that will be loaded on demand and contains all svg icons, when icon is needed to be displayed a regular expression should be able to select the group by its name for any supported icon. Example:

<g name="menu,back-arrow,close,plus,checked"><path....></g>

When one of the icons is needed ('close' for example) a regexp will be run through the file and the result will be used as innerHTML for the SVG element

2. use single template containing all elements and generate text from if (standard for soy templates) then use ids / names to retrieve the desired one. This gives us the possibility for class name minifications but we loose the new lines in the text file.

3. separate all SVG icons in separate files and load them on demand - this might prove to be volatile to network issues and is only a 'last resort' should all other possibilities fail.

From the 3 options, 2 seem to be a 'best fit' - it will however bump up the size of the whole compiler application a lot. Alternatively it can be loaded as 'module' by closure utils, but it will still require a lot of boilerplate (should the main app is not already 'modulized').

Ideal solution should be

1. have in memory only the icons that are used by the app (current solution and 3)
2. small footprint on load time (current solution)
3. ease of adding new icons (1)
4. fast access - no need for additional boilerplate (loader) code (current solution and 2)
5. use the minification algorithms of the compiler (current and 2)
6. work in offline mode (current, 2, 1 with local cache of the file (indexedDB etc))

Priority of the points:
Most important -> less important
6, 3, 4, 1, 2, 5

The button is visible in the UI the same was as the regular material button.