lundalogik / lime-elements Goto Github PK

Current behavior

When limel-button is created in the loading state using the following code, it shows the label "Save" instead of the spinner.

<limel-button label="Save" primary={true} loading={true} />

Expected behavior

The button should appear in the loading state, and display the spinner instead of the label.

Environment

• lime-elements version: 2.4.1
• Framework used: StencilJS (the docz page inside lime-elements)

Current behavior

 <limel-dialog
                open={this.dialogOpen}
                onClose={() => {
                    this.dialogOpen = false;
                }}
            >
                <h2>This is a dialog</h2>
                <limel-slider
                    label="Slider"
                    unit=" %"
                    value={50}
                    valuemax={100}
                    valuemin={0}
                />

Slider has incorrect width inside dialog. 100% is not at the most right.
Resizing the browser makes it re-render with the correct width.

Expected behavior

Environment

• lime-elements version: 7.1.0
• Framework used:
• Logs:

New feature motivation

Actually mostly because we want to try using a component from https://github.com/material-components/material-components-web-components, and the radio-button component is simple and seems to work well.

New feature description

Add a radio-button component called limel-radio.

New feature implementation

Use mwc-radio, wrapped in our own web component.

Tracked in the feature-waffle by Lundalogik/crm-feature#570

Current behavior

<limel-menu> incorrectly renders the menu items (as regular list, dotted <li>s)

Environment

• lime-elements version: 3.6.1
• Framework used: StencilJS

Copy paste the code in the lime-elements example for <limel-menu> in a lime-web-component.

Since this ListItem, ListSeparator aren't exported, create the list of items like:

private items: any = [
        { text: 'Visa på karta', action: 'openMap' },
        { separator: true },
        { text: 'Något annat' },
    ];

Current behavior

When setting the isOpen attribute to false/true, the collapsible section emits a close/open event

Expected behavior

The collapsible section should not emit a close/open event in response to setting the isOpen attribute

Connected to #152

Current behavior

Documentation is out of date, examples don't work

Expected behavior

• IOption is now Option
• import strings are incorrect*

Comment from @adrianschmidt:

Import strings are different inside and outside the project. Inside the project, the following is used:

import { Option } from '../../interface';

But the consumer, importing from an external source, should use:

import { Option } from 'lime-elements';

Since we can't change the imports in the examples, we need to add some documentation about this difference.

Environment

• lime-elements version: 5.0.0
• Framework used:
• Logs:

Tracked in the feature-waffle by Lundalogik/crm-feature#577

Currently, this code:

@Prop({reflectToAttr: true}) public size: string;

will be formatted like this by Prettier:

@Prop({reflectToAttr: true})
public size: string;

Unless Prettier is disabled for the specific line, like this:

@Prop({reflectToAttr: true}) public size: string; // tslint:disable-line:prettier

But that's annoying and fugly.

See if there's a way to instruct Prettier not to insert a linebreak, so it doesn't have to be disabled to preserve a reasonable formatting.

Current behavior

Closing a collapsible section inside a dialog closes the dialog as well

 <limel-dialog
                open={this.dialogOpen}
                onClose={() => {
                    this.dialogOpen = false;
                }}
            >
                <h2>This is a dialog</h2>

                <limel-collapsible-section>
                    <h5 slot="header">Do not close me!</h5>
                    <p slot="body">If you close me, you close the dialog!</p>
                </limel-collapsible-section>

                <limel-button-group reverse-order={true} slot="button">
                    <limel-button primary={true} label="Save" />
                    <limel-button label="Cancel" />
                </limel-button-group>
            </limel-dialog>,

Expected behavior

The opened dialog should remain open

Environment

• lime-elements version: 7.1.0
• Framework used:
• Logs:

Current behavior

Given the following code:

<limel-button
    label="Toggle"
    primary={true}
    onClick={() => {
        this.toggleExampleValue = !this.toggleExampleValue;
    }}
/>
<limel-switch
    label={`Current value: ${this.toggleExampleValue.toString()}`}
    value={this.toggleExampleValue}
    onChange={event => {
        this.toggleExampleValue = event.detail;
    }}
/>

When the button is clicked, the label updates correctly, but the switch does not change position.

Expected behavior

When the button is clicked, the switch should change position.

Environment

• lime-elements version: 5.1.0
• Framework used: StencilJS

• Define what components that we need to include in lime-elements
  • Based on what we need for the object card and for the customizations
• Define what components that we need to build ourselves
  • Datepicker - what should we do with that?
  • What other components are needed?
• Define rules for each component that must exist
  • UX-wise (Highest priority)
  • UI-wise
• Investigate if we get native input fields on mobiles
  • If not - how can we fix it?

New feature motivation

So far the limel-text-field just produces standard text inputs, but there is the need for inputs with a different html-type

New feature description

Add property type to the component and choose the html-type based on it

In the vanilla-material branch, if the examples has an scss-file, the source for that will be shown after the source for the tsx-file. This should be cleaned up a little. The different source types could be presented in tabs for example.

Also, the code for <limel-example> itself could probably be cleaned up a little by using the <PrismCode> component from react-prism

New feature motivation

If the husky precommit hook takes time because it lints all files even when none of the linted files have been changed, time is wasted and people will get annoyed and circumvent the hook.

New feature description

The precommit hook should only run the linting when there are files that need to be linted. If no such files have been changed, the linting should be skipped.

New feature implementation

There are ways to check the output of git status and trigger the applicable parts of the precommit hook based on that.

Current behavior

The property value of the limel-select has to be equals the display text of an option in order to be pre-selected. Simular to that when selecting an option the onChange emits the options value.

Expected behavior

Pre-selection as well as the value of the select input should be an unique key instead of the display text. When using the limel-select e.g in the object card form the lime-object can't be saved, because the value of the select is expected to be equals the options key.

Environment

• lime-elements version: 5.0.2
• Framework used: Angular (lime-webclient)

Current behavior

<limel-spinner hidden /> renders a visible spinner.

Expected behavior

<limel-spinner hidden /> should add a spinner, but it should be hidden.

Environment

• lime-elements version: 2.0.0

New feature motivation

We like to keep it fresh.

New feature description

I don't really know yet, it depends on what's new in Stencil.

New feature motivation

This component is used in many places throughout the desktop-client, and we already support it in the web-client, but it should be moved to lime-elements so it can be reused in plugins.

New feature description

A component for selecting multiple items in a set. Very similar to limel-select, but capable of selecting multiple items, not just one.

New feature implementation

limel-select uses the native select element, but there is no such native element that supports selecting multiple items, so this will have to be done in a different way. We need to be mindful of good mobile support though, as well as full keyboard support.

Make sure the interface resembles the new interface for limel-select, added in #129, and not the old one. That is, the value should most likely be an array of the selected objects, not just the keys of the selected objects.

Child of Lundalogik/crm-feature#457

Current behavior

Don't know if this is a feature or not, but after an item in a limel-menu has been clicked, it's disabled. In the Lime Elements docz example, it doesn't make much sense though, since you can only select eg "Copy" once, then you have to be able to select something else to be able to "Copy" again.

Expected behavior

The item should not be disabled on click, or at least that functionality should be a property.

Environment

• lime-elements version: [6.1.1, 7.1.0]
• Framework used:
• Logs:

There are some problems with the default test suite that comes with StencilJS, when using Shadow DOM. Find a way to test our components, and create at least a simple test for limel-button.

New feature motivation

We're using tabs in the webclient, and it's not unlikely that plugins might want to use them as well. They're also a somewhat complicated component, since the handling of tabs that overflow the width of the page can be done in several ways, all of which are complicated, except for the alternative to just wrap the overflowing tabs to a new line, but that is butt-ugly.

New feature description

Add a tabs-component :)

New feature implementation

The tabs-component in lime-webclient is a bit extra complicated, because it's been built such that the row of tabs and the "tab content" sections do not have to be attached. That is, you can choose to place the row of tabs in one place on the page, and the "pages" somewhere else entirely (unless it's been changed or my memory lets me down). IMHO, that's probably unnecessary, and lower complexity should be a higher priority.

New feature motivation

New feature description

Use icons in buttons, prepend text fields etc

New feature implementation

blocked by #111
Child of Lundalogik/crm-feature#503
Requires #137
Requires Lundalogik/crm-feature#583

Current behavior

Expected behavior

The menu should cover other page elements.

limel-picker ought to either use mdc-menu (or other relevant mdc-component), or use the same values for stuff like z-index.

Environment

• lime-elements version: 9.1.1
• Framework used: Angular/AngularJS (lime-webclient)

Tracked in the feature-waffle by Lundalogik/crm-feature#638

New feature motivation

A menu is a basic component that lime-elements should provide.

New feature description

Clicking the menu button should open the menu. Clicking on a menu-item should close the menu and inform the consumer which menu-item was selected. Clicking outside the menu should close the menu.

New feature implementation

The menu can probably make use of parts of limel-list.

Current behavior

A disabled limel-slider is looking exactly like the non disabled one. (it is however disabled as it should)

<limel-slider
    disabled={false}
    label="I'm ENABLED"
    unit=" %"
    value={50}
    valuemax={100}
    valuemin={0}
/>
<limel-slider
    disabled={true}
    label="I'm DISABLED"
    unit=" %"
    value={50}
    valuemax={100}
    valuemin={0}
/>
<limel-text-field
    disabled={false}
    label="Enabled"
    value="YES"
/>
<limel-text-field
    disabled={true}
    label="Enabled"
    value="NO"
/>

Expected behavior

Dimmed like the text-field in the example image

Environment

• lime-elements version: [6.1.1, 7.1.0]
• Framework used:
• Logs:

New feature motivation

We use collapsible sections extensively in the web-client, and these should be implemented in lime-elements instead, in order to improve modularisation, as well as making the component available to plugins.

New feature description

A collapsible section, with a header and a body. The header is always visible, but the body can be extended or collapsed by clicking the header.

The component should probably default to being initially collapsed, as that is the default of the component in lime-webclient. But it should be possible to initiate it in the open state as well.

New feature implementation

This should be a fairly simple component to implement. What will perhaps be more interesting is what happens when we use it in lime-webclient, as we'll be wrapping Angular-components in a non-Angular web-component.

New feature motivation

on a set-control from the core-api an option can be inactive and should then be not selectable in the multi-select component.

New feature description

use the diabled attribute of an option (similar to limel-select) to disable an option

We currently don't have any working test-runner for lime-elements.

There are (at least) two different levels that may or may not be relevant to test:

1. Traditional code-level unit-tests. Could be run in node or a browser like ChromeHeadless. This is what Jest, the test-runner included with Stencil, seems to be intended for.
2. UI-tests. Still on a unit-test kind of scale, but actually testing the rendered UI in a scripted browser. Preferably run in several different browsers when building PR-branches and master.

Number 1 seems like it might be easier to build, but there are some issues with lacking support for shadow-DOM in the libs used by Jest, which is why this wasn't set up to begin with. At first, the components in lime-elements where a bit too simple to really warrant this testing level, but I think that has changed now, and we really do have a need for this.

Current behavior

while limel-picker expects a object as value, the limel-select value is a string, that has to match the key of one of the items

Expected behavior

we should decide on one way how to define an object in a list. I would lean to using a object, since that might be less confusing in terms of which attribute the string has to match to.

New feature motivation

It's much easier to read a changelog file than the list of releases on GitHub. Also, people expect there to be a CHANGELOG.md in the project root.

New feature description

What it says there ☝️

New feature implementation

We really want semantic-release to create and update the file automatically. No manual work!

New feature motivation

We need a grid system to do simple layouts. Without an official one, addons will be very inconsistent, just like the actionpads before Lime Bootstrap.

New feature description

A simple row/col system with offset would probably be sufficient.

Current behavior

• Clone lime-elements repo on Windows
• Run >npm install
• Run >npm start
• The issue with SASS_PATH can be solved with cross-env
• The trickier problem is that stencil.config.ts is treated as a .js file by node for some reason, which causes a parsing error.

Expected behavior

Running >npm start should work the same on Windows as on Linux

Environment

• lime-elements version: 3.6.1
• Framework used: Just npm start
• Logs: "Unexpected token { C:\Users\IEUser\GIT\lime-elements\stencil.config.dev.ts:1 ..."

Current behavior

The spinner is always the same size, regardless of the value of the size attribute.

Expected behavior

The spinner should accept the values mini, x-small, small, medium, and large, and change size accordingly.

Environment

• lime-elements version: 2.0.0

New feature motivation

In some cases we don't want the user to be able to close the dialog by clicking outside the dialog or pressing the escape key. Such a case is when an active choice of something has to be made and cancelling by clicking outside the dialog should not be allowed.

New feature description

As suggested by @adrianschmidt, a new dialog "type" property could be used to abstract the properties and also set other properties.

New feature implementation

https://github.com/material-components/material-components-web/tree/master/packages/mdc-dialog#dialog-actions

New feature motivation

Users of lime-elements should not need to have and build the source code to be able to read the documentation.

New feature description

docz can be built for dist already. We should do that and publish the result somewhere when releasing. GitHub Pages seems like the obvious place, at least once we open the repo publicly.

It would be nice if we could keep revisions of the docs, so that the user will land on the docs for the latest release, but can choose any previous release from a dropdown.

New feature implementation

I've got a pretty nice solution for publishing to GitHub Pages in Pocket Dragon. We might be able to use some ideas from there, and have Jenkins push the docs after each successful release.

Current behavior

limel-dialog is shown cramped in within the related-view and not in the whole browser window when opened.

Expected behavior

The limel-dialog should appear as it does when it's opened from a lime-object container modal style with backdrop

Environment

• lime-elements version: 2.2.1

• Framework used: StencilJS

• Logs: Nothing more but the unrelated usual focus-trap error

Current behavior

When setting the open attribute to false when a dialog is open, the dialog emits a close event

Expected behavior

The dialog should not emit a close event in response to setting the open attribute to false

Connected to #152

Current behavior

1. Open the docz-app and go to the dialog-example.
2. Click the Open-button.
3. Click on the greyed out background outside the dialog.
4. When the dialog has closed, click the Open-button again.

Nothing happens.

Expected behavior

The dialog should open again.

Environment

• lime-elements version: 7.1.0
• Framework used: StencilJS

New feature motivation

De-style the UI to use vanilla material design where possible. Benefits:

• we focus on creating a platform for now, not styling

New feature description

Material UI

New feature implementation

Removing custom styling

Tracked in the feature-waffle by Lundalogik/crm-feature#579

Current behavior

npm install in lime-webclient fails on lime-elements

Expected behavior

npm install in lime-webclient should work

Environment

• lime-elements version: 5.0.0
• Framework used: lime-webclient
• Logs: npm ERR! 404 Not Found: [email protected]

Current behavior

When having a dialog open, it's possible to tab to an element on the page "behind" the dialog.

Expected behavior

When having a dialog open, focus is "trapped" within the dialog, and it's not possible to tab to an element on the page "behind" it.

Environment

• lime-elements version: limel-dialog is not yet released
• Logs: (I'll add the error message here later)

The problem appears because focus-trap used by mdc-dialog does not yet support shadow DOM.
Issue on focus-trap: focus-trap/focus-trap#39
See this comment specifically for the suggested work-around: focus-trap/focus-trap#39 (comment)

Update 2019-02-14

The changes made in #291 means we no longer get an error thrown when opening the dialog, but focus still isn't properly trapped. But I think it might be possible for us to get the trapping to work properly if we just tweak that code a little bit.

Current behavior

When entering text, the component is set to loading. It then watches the items property for changes to disable the loading-state again.

Expected behavior

The consumer should supply a search-function, which should return a promise when a search is initiated.

Environment

• lime-elements version: 3.2.0

Tracked in the feature-waffle by Lundalogik/crm-feature#589

Current behavior

Create a limel-select component where the options array is empty.
After the component is created, add some options to the array.
The options are now visible, but the label is not floating.

Expected behavior

The label should float, just as it does if the options array is already populated when the component is created.

Environment

• lime-elements version: 5.1.1
• Framework used: StencilJS

Tracked in the feature-waffle by Lundalogik/crm-feature#578

Icon as an optional attribute on ListItem must be supported by a number of components.

• List
• Menu
• Picker

Improve the picker component to use the chip set component to display the selected values

requires #172