Currently we are running into some issues when running lerna run tests. It attempts to start up multiple instances of karma, which can cause collisions since they are starting up servers.

We also have issues with how dependencies are resolved, see discussion on #14.

The proposed solution is to run the tests from the root directory of the project similarly to how metal.js does it.

We need to add elementClasses param to ClayIcon

Currently using jsx to render a pie chart. When I change the data passed into the columns prop, I get a js error in the console.

billboard.js:9310 Uncaught TypeError: Cannot convert undefined or null to object
at Function.keys ()
at Chart.load (billboard.js:9310)
at PieChart.handleColumnsChanged_ (ChartBase.js:360)
at PieChart.runListeners_ (EventEmitter.js:463)
at PieChart.emit (EventEmitter.js:189)

I think this stems from not having a default value for the colors arg on data items

Two data sets I am switching between.

[
	{
		data: [230, 190, 300, 500, 300, 400],
		id: 'data1',
	},
	{
		data: [50, 20, 10, 40, 15, 25],
		id: 'data2'
	}
]


[
	{
		data: [10],
		id: 'data3',
	},
	{
		data: [20],
		id: 'data4'
	}
]

All DelTemplates need to have the same param declarations. Otherwise, when compiled together, an error is thrown:

In file 1076_BUNDLE_CONTEXT_/META-INF/resources/node_modules/[email protected]/src/ClayUserCard.soy:53:1, template ClayCard.DescriptiveArea:user: Found delegate template with same name 'ClayCard.DescriptiveArea' but different param declarations compared to the definition at 1076_BUNDLE_CONTEXT_/META-INF/resources/node_modules/[email protected]/src/ClayCard.soy:98:1

Currently, ClayCard.soy DescriptiveArea is different than ClayUserCard.soy DescriptiveArea

Posting an issue here because we have a need for a Datepicker component. I believe there is already one somewhere in Lexicon, however I wasn't able to find it on any of the documentation sites.

Is this something that we will see worked on here?

\cc @Robert-Frampton @bryceosterhaus @pat270

Success and warning icons are not correct. See mockup for reference.

In JSP some users need to pass attributes to their components and one way was to use the data parameter like HashMap, Use cases like when you want a link not to use the SPA, passing data-senna-off.

Since icon-monospaced has been removed from Clay we should remove monospaced param as well from the component.

And since btn-monospaced exists we should add monospaced param to ClayButton component.

We need to update the markup

In our components there're some params that are required. In those cases if the param is not passed the component throws an exception.

If we test that like in https://github.com/metal/metal-clay-components/blob/master/packages/clay-alert/src/__tests__/ClayAlert.js#L207 tests passes but in console appears the expected error.

Should we test those cases? If yes, we have to update all our tests with this and find out a way to hide those errors from the logs (like stubbing console.error). If not, we need to remove those tests from ClayAlert and ClayNavbar.

What do you guys think?

When running lerna run test it's unable to find a local package.

Uncaught Error: Could not find module '../../metal-quartz-icon/src/MetalQuartzIcon' from '/metal-quartz-components/packages/metal-quartz-link/src/MetalQuartzLink.js'
at node_modules/karma-commonjs/client/commonjs_bridge.js:85

All clay components should be shown over white background instead of current grey.

We need to replace old markup with new one.

ClayDropdownBase doesn't support the flag separator for the regular items (type items). Does nothing and it should render a separator if true.

Just continuing the #134 dialog so that we can get to a ClayAlert API definition.

The way we treat the ClayAlert API as just an alert, prevents us from adding the types of notifications.

• Alert Notifications Fixed
• Alert Notifications Absolute

Both wrap up several alerts so they can be stacked, for example:

<div class="alert-notifications alert-notifications-fixed">
    <div class="alert ..."></div>
    <div class="alert ..."></div>
    <div class="alert ..."></div>
    <div class="alert ..."></div>
</div>

That way we can not support ClayAlert this option. I want to leave my vision on this so that we can arrive at a better experience.

Proposal

Option 1

We can refactor the entire ClayAlert API so that devs can pass multiple alerts on the component.

Example:

{
	alerts: [
		{
			autoClose: true,
			message: '',
			style: 'success',
			title: 'Success',
			type: 'fluid',
		},
		{
			message: '',
			style: 'warning',
			title: 'Warning',
			type: 'fluid',
		}
	],
	spritemap: spritemap,
}

The bad thing about this approach is that we give a certain "freedom" for devs to be able to pass several nested alerts and we can not control it, I do not feel secure about it.

In use cases where you only want to pass only an information alert the use of ClayAlert may become complex in a taglib JSP for example what was meant to be simple.

Example:

{
	alerts: [
		{
			autoClose: true,
			message: '',
			style: 'success',
			title: 'Success',
			type: 'fluid',
			alerts: [
				{
					message: '',
					style: 'warning',
					title: 'Warning',
					type: 'fluid',
				}
			]
		}
	],
	spritemap: spritemap,
}

Option 2

We can maintain the current ClayAlert API and treat notification types as a second component, making it optional, and making ClayAlert simple to use in cases where the dev only wants to display an alert message.

Example of the use in soy:

{call ClayAlertTypeNotification.render}
	{param content kind="html"}
		{call ClayAlert.render}
			{param message: '' /}
			{param title: 'Info' /}
		{/call}
		{call ClayAlert.render}
			{param message: '' /}
			{param title: 'Info' /}
		{/call}
		{call ClayAlert.render}
			{param message: '' /}
			{param title: 'Info' /}
		{/call}
	{/param}

	{param type: 'fixed' /}
{/call}

Unlike the second option the use of ClayAlert becomes simpler in a taglib jsp when dev just wants to display an alert message.

cc @carloslancha, @jbalsas

We need to remove badge-pill class according to Clay 2.0.0Beta

What do you guys think about we use the same .editorconfig of Metal Components?
https://github.com/metal/metal-tabs/blob/master/.editorconfig

Even we don't pick the same configuration I think we should use any.

cc. @jbalsas, @pat270, @Robert-Frampton, @brunobasto

This issue is keeping track of Clay V2 migration

Components that are safe to work on:
Alerts
Badges, Labels, Stickers
Breadcrumbs
Buttons
Dropdowns
Form Elements
Form Element Input groups
Icons Clay SVG's
Modals
Multi Step Nav
Pagination
Panels (Keeping Panels)
Popovers
Progress Bars
Tables
Timelines
Toggles

(REMOVED) Figures
(REMOVED) Header Toolbar
(REMOVED) Icons Font Awesome
(REMOVED) Icons Glyphicons
(REMOVED) Nameplates
(REMOVED) Pager
(REMOVED) Toolbars
(REMOVED) User Icons

Components still pending:
Form Element Validation
Cards
List Groups
Loading Indicators (might remove this)
Mangement Bar
Navigation Bar
Navbars (This is a base component that is used by Management Bar, Navigation Bar, and potentially Other Bars)
Nav
Nav Underline
Nav Tabs
Sidebar
Subnav
Tooltips

When we use a component as a dependency that uses another component as a dependency we need to add both as dependencies in our component in order to make soy compile working.

The problem is with metalsoy --soyDeps, as a workaround we made this:

7319a94#diff-487d9b9c11d483b0c92610dbf8612825R21

Saw that we use yarn for this repo. I was wondering why we switched to this since Metal.js repo is using npm. IMO its a little confusing to change up tooling between repos. I have nothing against yarn, I just prefer consistency between repos in the org.

We have params for css classes block, size, style. Can we let the user define these css classes through elementClasses?

We have params for attributes disabled, href, name, type, value. Can we let the user define these attributes through a single property like htmlAttributes? That way we don't limit anyone to just these attributes.

Do we really need an specific parameter icon in this component?

If we want ClayLink to render an icon we can just pass it in the label.

What do you think?

At the moment, we have different ways of "sorting" imports and it would be nice to have a consistent way of doing it.

Here's an example to explain this a bit further.

# let's create a file with some content
cat>>test.js
import {Config} from 'metal-state';
import Component from 'metal-component';
import templates from './MyTemplate.soy.js';
# C-d to save and exit

If you use the sort command

sort test.js

The output is the following:

import Component from 'metal-component';
import templates from './MyTemplate.soy.js';
import {Config} from 'metal-state';

However, if you open this same test.js file with VSCode the and use the Sort Lines Ascending (which can be accessed with the CMD + Shift + p key combination) the output is different and looks like this:

import {Config} from 'metal-state';
import Component from 'metal-component';
import templates from './MyTemplate.soy.js';

Let's find a consistent way of doing this.

Maybe eslint-plugin-import-order-autofix could be a solution.

Hey guys,

We can improve the organization of packages in packages, we have some packages like generator-clay and browserslist-config-clay-components that are somewhat inconsistent with the clay-tag.

I think of the following structure.

.
+-- packages
|   +-- clay/
|   +-- utility or utils/

.
+-- packages/
+-- utility/

What do you think about this ?

We need to update markup to clay 2.0.0 Beta.

Disclaimer

ClayRadio component renders a markup that violates accessibility standards when using multiple elements with the same name attribute. Rendering multiple ClayRadio elements with the same name must be wrapped by either a <fieldset> element or a container having role="radiogroup" applied on it.

Expected markup

<div role="radiogroup">
  <input type="radio" name="myInput" role="radio" value="1" />
  <input type="radio" name="myInput" role="radio" value="2" />
</div>

Proposal

To create a ClayRadioGroup component that implements a functionality to incorporate various ClayRadio components that are intended to have the same name attribute and renders them inside of a wrapper that contains the required role="radiogroup".

  new ClayRadioGroup(
  {
    items: [
      new ClayRadio( // .... ),
      new ClayRadio( // .... )
    ]
  },
  '#my-radio-group'
);

We've recently seen differences into how soy gets rendered Server-Side and Client-side. See #162 for an example.

We need to investigate a way to tests Server-Side Rendering of the Soy templates to make sure everything is rendering as expected.

We are currently ignoring a lot of packages from soy linting because it gives us problems. We need to enable it again or we risk introducing bugs and inconsistencies.

Hey Guys,
I got a feature request on the Clay Repo that I think fits better here. See liferay/clay#391.

Have the ability to order drop down menus by alphabetical order ascending or descending based on a data attribute on the element containing the dropdown-menu class. Something like aria-sortby or data-sortby="alpha-asc" (alpha-asc, alpha-desc, none)

/cc @duracell80

Reusable component that renders an anchor tag with a set list of attributes, will provide a consistent api across components that use links.

Currently ClayCheckbox and ClayRadio can not customize your label, there are cases like Card that we can make a Card as a checkbox.

I think we can make ClayCheckbox with a ClayCheckboxBase base class so we can have more customization power and make the ClayCheckbox class available to use as the current one.

- ClayCheckbox.js
- ClayCheckboxBase.js

In this thought we keep Checkbox markup control centralized in one place ClayCheckboxBase.

What do you guys think about that?

The clay component generator is missing some of the last additions like .eslintrc default config and default npm scripts

https://github.com/metal/metal-clay-components/blob/master/packages/clay-button/src/ClayButton.js#L106

When running npm test first action executed is lerna run soy. If there're any soy errors they won't show up in console. i.e:

• Add not used parameter in packages/clay-button/src/ClayButton.soy

{@param? type: string}
{@param? value: string}
{@param? notUsedParam: string}

• Run npm test from root. Should appear an error like:

FAIL  packages/clay-button/src/__tests__/ClayButton.js
  Test suite failed to run
    Cannot find module './ClayButton.soy.js' from 'ClayButton.js'
      
      at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:179:17)
      at Object.<anonymous> (packages/clay-select/src/ClayButton.js:7:22)

• That's because ClayButton.soy.js wasn't generated due build errors, but nothing warns you about those errors at least you run npm run build inside the package.

Compiling soy
Error in plugin 'metal-tools-soy'
Message:
    Compile error:
errors during Soy compilation
src/ClayButton.soy:6: error: Param 'notUsedParam' unused in template body.
{template .render}
^
1 error

It has been decided to reduce the metal.js surface to only core+plugins as it was always intended.

For that reason, we have already started deprecating and archiving all the ui-related metal components. We should remove all dependencies in this project like metal-dropdown and keep our own versions as they will no longer be available in the future.

[email protected] is out, and with it the possibility of generating WebComponents automatically

We should update all clay components so that they are exposed as WebComponents as well!

/cc @carloslancha, @matuzalemsteles

Until now we're hardcoding some strings like "Search" or "Close" in the components. We need to find out a way to manage this texts to be localizable.

Should function similar to Bootstrap's collapse component (http://getbootstrap.com/javascript/#collapse).

High-level components such as ListGroup are hard to pin down when it comes to what content is going to be rendered in them.

For that reason, it would be good to provide a customizable contentRenderer deltemplate of some sort so consumers can pass down the template to be used in the content portion for the items.

Is it even possible to listen for initialization events? Currently the only way to listen for these events would be to access the ref of the component, but by the time we have access to the ref I think the component will have already fired this event.

For example:

import Component, {Config} from 'metal-jsx';
import {BarChart, PieChart} from 'metal-charts';

class MyComponent extends Component {
	attched() {
		this.refs.chart.on('chartInit', () => {
			// This will never actually fire
			console.log('fire');
		});
	}
	
	render() {
		return (
			<PieChart ref="chart" />
		);
	}
}

export default MyComponent;

I am trying to add something like https://jsbin.com/boyusuz/3/edit?html,js,output

Based on Lexicon Alert Pattern, the fluid type of alert is actually called stripe. For simpler usage and mapping, we should match Lexicon's type.

Also,

The close action is mandatory in this alert type.

So it shouldn't be necessary to set closeable to true for these type of alerts.

https://github.com/liferay/liferay-portal/tree/master/modules/apps/foundation/frontend-taglib/frontend-taglib/src/main/resources/META-INF/resources/management_bar