Socket
Socket
Sign inDemoInstall

@lion/core

Package Overview
Dependencies
Maintainers
1
Versions
66
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@lion/core - npm Package Compare versions

Comparing version 0.17.0 to 0.17.1

6

CHANGELOG.md
# Change Log
## 0.17.1
### Patch Changes
- d1d977c1: Update to latest lit v1
## 0.17.0

@@ -4,0 +10,0 @@

75

docs/guides/how-to/creating-a-custom-field.md

@@ -1,74 +0,3 @@

# How To >> Creating a custom field ||20
# Creating a custom field
```js script
import { html, render } from '@lion/core';
import { Validator } from '@lion/form-core';
import '@lion/input/define';
import '../../docs/systems/form/assets/h-output.js';
```
Custom fields can be created in just a few steps. All you need is an interaction element (like for instance a slider, a listbox or a combobox) and connect it to the [input components](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/components/inputs/input/overview.md).
## Prerequisite: an interaction element
An interaction element provides the means for the end user to enter a certain value, just like native elements provide in this (think of `<input>`, `<textarea>` and `<select>`). An example of a non native element is the [slider design pattern](https://www.w3.org/TR/wai-aria-practices-1.1/#slider) described here.
For this tutorial, we assume we have a component `<my-slider>` that exposes its value via property `mySliderValue` and sends an event `my-slider-changed` on every value change. To make it focusable, it has a tabindex=“0” applied.
## Connecting the interaction element to the field
Now we want to integrate the slider in our form framework to enrich the user interface, get
validation support and get all the other [benefits of LionField](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/docs/systems/form/overview.md). We start by creating a component `<lion-slider>` that extends from `LionField`. Then we follow the steps below:
### 1. Add your interaction element as ‘input slot'
Here you return the element the user interacts with. By configuring it as a slot, it will end up in light DOM, ensuring the best accessibility for the end user.
### 2. Proxy event `my-slider-changed` to `user-input-changed` event
The `user-input-changed` event is listened to by the FormatMixin: it should be regarded as the equivalent of the `input` event of the platform, but for custom built interaction elements.
### 3. Proxy property `<my-slider>.mySliderValue` to `<lion-slider>.value`
Every time the `user-input-changed` fires, the value of `<my-slider>` is synchronized with the [`modelValue`](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/docs/systems/form/model-value.md) of `<my-slider>`. Now the cycle is complete: the modelValue connects your interaction element to all logic inside the LionField.
Steps as described can be implemented with the following javascript:
```js
import { LionField } from '@lion/form-core';
import './my-slider.js';
export class LionSlider extends LionField {
// 1. Add your interaction element as ‘input slot'
get slots() {
return {
...super.slots,
input: () => document.createElement(‘my-slider’),
};
}
// 2. Proxy event `my-slider-changed` to `user-input-changed` event
connectedCallback() {
super.connectedCallback();
this.addEventListener('my-slider-changed', this._proxyChangeEvent);
}
_proxyChangeEvent() {
this._inputNode.dispatchEvent(
new CustomEvent('user-input-changed', { bubbles: true, composed: true }),
);
}
// 3. Proxy property `<my-slider>.mySliderValue` to `<lion-slider>.value`
get value() {
return Array.from(this.children).find(child => child.slot === 'input').mySliderValue;
}
set value(newV) {
Array.from(this.children).find(child => child.slot === 'input').mySliderValue = newV;
}
}
```
That was all. Now you can enhance your slider by writing custom validators for it or by writing a parser to get a custom modelValue type.
[=> See Source <=](../../../../../docs/guides/how-to/creating-a-custom-field.md)

@@ -1,75 +0,3 @@

# How To >> Get Started ||10
# Get Started
## Technologies Used
Lion Web Components aims to be future proof and use well-supported proven technology. The stack we have chosen should reflect this.
Checkout the documentation of our main stack.
- [lit-html](https://lit-html.polymer-project.org) - An efficient, expressive, extensible HTML templating library for JavaScript.
- [lit-element](https://lit-element.polymer-project.org) - A simple base class for creating fast, lightweight web components.
- [modern-web](https://modern-web.dev) - Guides, tools and libraries for modern web development.
- [open-wc](https://open-wc.org) - Open Web Components provides guides, tools and libraries for developing web components.
## How to get started
Make sure you have `npm`, if you don't have it yet: [get npm](https://www.npmjs.com/get-npm).
And create a repo, we suggest to use [the generator from open-wc](https://open-wc.org/docs/development/generator/):
```bash
npm init @open-wc
```
### Install lion packages
```bash
npm i @lion/<package-name>
```
### Extend a Web Component
**This is the main use case for lion**. To import component classes, and extend them for your own design system's components.
```js
import { css } from '@lion/core';
import { LionInput } from '@lion/input';
class MyInput extends LionInput {
static get styles() {
return [
...super.styles,
css`
/* your styles here */
`,
];
}
}
customElements.define('my-input', MyInput);
```
### Use a JavaScript system
There's a couple of "systems" in lion which have a JavaScript API. Examples are `localize`, `overlays`, `ajax`, etc.
```html
<script type="module">
import { ajax } from '@lion/ajax';
ajax.get('data.json').then(response => {
// most likely you will use response.data
});
</script>
```
### Use a Web Component
You can also use the lion elements directly, although this is likely not a common use case.
```html
<script type="module">
import '@lion/input/lion-input.js';
</script>
<lion-input name="firstName" label="First name"></lion-input>
```
[=> See Source <=](../../../../../docs/guides/how-to/get-started.md)

@@ -1,1 +0,3 @@

# How To ||20
# How To
[=> See Source <=](../../../../../docs/guides/how-to/index.md)
# Guides
Lion is a set of white label Web Components that can be extended to your own styled layer of components.
We know from experience that making high quality, accessible UI components is hard and time consuming: it takes many iterations, a lot of development time and a lot of testing to get a generic component that works in every context, supports many edge cases and is accessible in all relevant screen readers.
Lion aims to do the heavy lifting for you. This means you only have to apply your own Design System: by delivering styles, configuring components and adding a minimal set of custom logic on top.
## Consuming Developer
Developers consuming our web components inside an application (not extending them).
`Application Developers` are only allowed to interact with `public` properties and methods.
Can be abbreviated as `AD`. Sometimes also called `Consuming Developer`.
- [Definitions and Terms](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/guides/principles/definitions-and-terms.md)
- [Styling](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/guides/principles/styling.md)
- [Scoped Elements](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/guides/principles/scoped-elements.md)
## Extending Developer
Developers extending our web components, for instance: `class MaterialInput extends LionInput` are called `subclassers`. Subclassers have access to protected methods (prefixed with an underscore or marked as protected), but not to private methods.
Especially for subclassers we have some extra documentation:
- [Subclasser APIs](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/guides/principles/subclasser-apis.md)
- [Extend documentation](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/blog/extending-documentation)
## How To
Next to that we have some specific "How To" documentations.
- [Get started](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/guides/how-to/get-started.md)
- [Create a custom field](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/guides/how-to/creating-a-custom-field.md)
[=> See Source <=](../../../../docs/guides/index.md)

@@ -1,41 +0,3 @@

# Principles >> Definitions and Terms ||20
# Definitions and Terms
Below you will find a list of definitions and terms that will be used throughout our code
documentation.
## Public
Methods and properties are public when they are not prefixed by an underscore.
They can be used by Application Developers.
```js
class SoccerPlayer {
kickBall() {
// Soccer player can kick a ball
}
}
```
## Protected
Methods and properties are protected when they contain one underscore or are explicitly marked as protected in the code. They can be used by Subclassers.
```js
class SoccerPlayer {
_catchBall() {
// Soccer player usually does not need to catch a ball (with their hands)
}
}
```
## Private
Methods and properties are protected when they contain two underscores or are explicitly marked as private in the code. They can be only used within the class where they are defined (developers of Lion components).
```js
class SoccerPlayer {
__score() {
// internally save how many goals have been made
}
}
```
[=> See Source <=](../../../../../docs/guides/principles/definitions-and-terms.md)

@@ -1,1 +0,3 @@

# Principles ||10
# Principles
[=> See Source <=](../../../../../docs/guides/principles/index.md)

@@ -1,101 +0,3 @@

# Principles >> Scoped Elements ||40
# Scoped Elements
The [CustomElementRegistry](https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry) provides methods for registering custom elements. One of the limitations of working with this global registry is that multiple versions of the same element cannot co-exist. This causes bottlenecks in software delivery that should be managed by the teams and complex build systems. [Scoped Custom Element Registries](https://github.com/w3c/webcomponents/issues/716) is a proposal that will solve the problem. Since this functionality won't be available (especially not cross browser) anytime soon, we've adopted [OpenWC's Scoped Elements](https://open-wc.org/docs/development/scoped-elements/).
Whenever a lion component uses composition (meaning it uses another lion component inside), we
apply ScopedElementsMixin to make sure it uses the right version of this internal component.
```js
import { ScopedElementsMixin, LitElement, html } from '@lion/core';
import { LionInput } from '@lion/input';
import { LionButton } from '@lion/button';
class MyElement extends ScopedElementsMixin(LitElement) {
static get scopedElements() {
return {
'lion-input': LionInput,
'lion-button': LionButton,
};
}
render() {
return html`
<lion-input label="Greeting" name="greeting" .modelValue=${'Hello world'}></lion-input>
<lion-button>Save</lion-button>
`;
}
}
```
## Query selectors
Since Scoped Elements changes tagnames under the hood, a tagname querySelector should be written like this:
```js
this.querySelector(
this.constructor.getScopedTagName('lion-input', this.constructor.scopedElements),
);
```
## CSS selectors
Avoid tagname css selectors.
We already avoid query selectors internally in lion, but just be aware that a selector like
```css
lion-input {
padding: 20px;
}
```
will stop working.
## Edge cases
Sometimes we need to render parts of a template to light dom for [accessibility](https://wicg.github.io/aom/explainer.html). For instance we render a node via `lit-html` that we append to the host element, so it gets slotted in the right position.
In this case, we should also make sure that we also scope the rendered element.
We can do this as follows:
```js
_myLightTemplate() {
return html`
This template may be overridden by a Subclasser.
Even I don't end up in shadow root, I need to be scoped to constructor.scopedElements as well.
<div>
<lion-button>True</lion-button>
<lion-input label="xyz"></lion-input>
</div>
`;
}
__getLightDomNode() {
const renderParent = document.createElement('div');
this.constructor.render(this._myLightTemplate(), renderParent, {
scopeName: this.localName,
eventContext: this,
});
// this node will be appended to the host
return renderParent.firstElementChild;
}
connectedCallback() {
super.connectedCallback();
this.appendChild(this.__getLightDomNode());
}
```
In a less complex case, we might just want to add a child node to the dom.
```js
import { ScopedElementsMixin, LitElement, getScopedTagNamegetScopedTagName } from '@lion/core';
...
__getLightDomNode() {
return document.createElement(getScopedTagName('lion-input', this.constructor.scopedElements));
}
```
We encourage you to have a look at [OpenWC's Scoped elements](https://open-wc.org/docs/development/scoped-elements/).
[=> See Source <=](../../../../../docs/guides/principles/scoped-elements.md)

@@ -1,32 +0,3 @@

# Principles >> Styling ||30
# Styling
## Markup and styling
All Lion web components have white label styling: this means theming is not applied,
but functional styling is.
### Functional styling
Functional styling can be divided into defaults for `basic layout` and `accessibility`.
Examples for both categories can be found below:
- Basic layout examples:
- A dropdown menu has `position: absolute;`.
- A lion-button might behave as an `display: inline-block;` element.
- A suffix attached to an input is horizontally positioned (instead of vertically stacked).
- Accessibility examples:
- Content (for instance a caption in a table) can be `visually hidden`: it will be
readable by screen readers, but invisible for end users.
- When an html table is used, we allow [subclassers](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/guides/principles/subclasser-apis.md) to override the display property (`table-cell`) to `flex`. By putting the proper accessible roles (`role="cell"`) in the markup, we guarantee our markup stays accessible.
Although Lion components try to stay as unbiased as possible with regard to styling, defaults will be needed. In these cases we try to follow the platform as much as possible. If the platform doesn't provide defaults, the largest common denominator across existing UI frameworks is taken as a lead.
## CSS variables
Css variables will not be added in our white label style components, but adding them in your own extension layer would be a perfect fit.
## Parts and themes
The `::part` and `::theme` specs might currently not be widely adopted enough to be used inside style components. When they are, we could be consider to add them later to our components as a means to theme components (changing a whole Design System is not a good idea).
[=> See Source <=](../../../../../docs/guides/principles/styling.md)

@@ -1,28 +0,3 @@

# Principles >> Subclasser apis ||50
# Subclasser apis
In order to make it easy for Subclassers to extend our components, we follow a certain set
of best practices naming conventions to make our code predictable.
## Templates
### Template naming conventions
For templates that do need access to the instance of the web component there is a prefix `_render/__render`.
Examples are `__renderHeader` and `__renderData`.
### Separation of concerns
Our components should make it possible to override markup and styling, without having to redefine
functionality.
By using the spread directive, we can achieve this. For more info, see [explanation](https://github.com/ing-bank/lion/issues/591).
## Node references
As a Subclasser, you sometimes need access to a protected node inside the shadow dom.
Most functional nodes have their own getters. A Subclasser can access those in his extension and
in some cases, override these getters.
### Node naming conventions
A node reference will have an underscore prefix and always ends with `Node`.
Examples are `_inputNode` and `_formNode`.
[=> See Source <=](../../../../../docs/guides/principles/subclasser-apis.md)

@@ -1,84 +0,3 @@

# Systems >> Core >> Overview ||10
# Lion Core Overview
The core package is mostly for in-depth usage.
It handles the version of `lit-element` and `lit-html`.
To be sure a compatible version is used you should import it via this package.
```js
// DO
import { LitElement, html, render } from '@lion/core';
// DON'T
import { LitElement, html, render } from 'lit-element';
```
## Features
- [function to deduplicate mixins (dedupeMixin)](https://github.com/ing-bank/lion/blob/4bd5e4fc4dcadd802d0856c0e73e3af559f40537/docs/docs/systems/core/#deduping-of-mixins)
- Mixin to handle disabled (DisabledMixin)
- Mixin to handle disabled AND tabIndex (DisabledWithTabIndexMixin)
- Mixin to manage auto generated needed slot elements in light dom (SlotMixin)
> These features are not well documented - care to help out?
## Installation
```bash
npm i --save @lion/core
```
```js
import { dedupeMixin, LitElement } from '@lion/core';
```
### Example
```js
const BaseMixin = dedupeMixin((superClass) => {
return class extends superClass { ... };
});
```
## Deduping of mixins
### Why is deduping of mixins necessary?
Imagine you are developing web components and creating ES classes for Custom Elements. You have two generic mixins (let's say `M1` and `M2`) which require independently the same even more generic mixin (`BaseMixin`). `M1` and `M2` can be used independently, that means they have to inherit from `BaseMixin` also independently. But they can be also used in combination. Sometimes `M1` and `M2` are used in the same component and can mess up the inheritance chain if `BaseMixin` is applied twice.
In other words, this may happen to the protoype chain `... -> M2 -> BaseMixin -> M1 -> BaseMixin -> ...`.
An example of this may be a `LocalizeMixin` used across different components and mixins. Some mixins may need it and many components need it too and can not rely on other mixins to have it by default, so must inherit from it independently.
The more generic the mixin is, the higher the chance of being appliend more than once. As a mixin author you can't control how it is used, and can't always predict it. So as a safety measure it is always recommended to create deduping mixins.
### Usage of dedupeMixin()
This is an example of how to make a conventional ES mixin deduping.
```js
const BaseMixin = dedupeMixin((superClass) => {
return class extends superClass { ... };
});
// inherits from BaseMixin
const M1 = dedupeMixin((superClass) => {
return class extends BaseMixin(superClass) { ... };
});
// inherits from BaseMixin
const M2 = dedupeMixin((superClass) => {
return class extends BaseMixin(superClass) { ... };
});
// component inherits from M1
// MyCustomElement -> M1 -> BaseMixin -> BaseCustomElement;
class MyCustomElement extends M1(BaseCustomElement) { ... }
// component inherits from M2
// MyCustomElement -> M2 -> BaseMixin -> BaseCustomElement;
class MyCustomElement extends M2(BaseCustomElement) { ... }
// component inherits from both M1 and M2
// MyCustomElement -> M2 -> M1 -> BaseMixin -> BaseCustomElement;
class MyCustomElement extends M2(M1(BaseCustomElement)) { ... }
```
[=> See Source <=](../../../docs/docs/systems/core/overview.md)

@@ -1,203 +0,3 @@

# Rationales >> Side Effects ||10
# Side Effects
All our packages are side effect free due to the fact that es modules are always side effect free even when changing other es modules. Only code which accesses browser globals like `window`, `console` in the root of the module will be treated a side effect and always included.
Everything else can be tree shaken by [rollup](https://rollupjs.org).
## Example
In this example we will define a function to override an es module export.
👉 `main.js`
```js
import { somethingElse, overlays } from './overlays.js';
console.log(somethingElse);
```
👉 `overlays.js`
```js
class OverlayManager {}
export let overlays = new OverlayManager();
export function setOverlays(newOverlays) {
overlays = newOverlays;
}
export const somethingElse = 'something else';
```
### Example Result
However having this function alone does not mean a side effect as rollup can tree shake it.
See the code in [rollup repl][1].
```js
const somethingElse = 'something else';
console.log(somethingElse);
```
## Example Override
Let's add an es module which uses that override.
👉 `main.js`
```js
import { somethingElse, overlays } from './overlays.js';
import './override.js';
console.log(somethingElse);
// this will trigger loading of full overlays.js & override.js code
// console.log(overlays.list);
```
👉 `override.js`
```js
import { setOverlays } from './overlays.js';
setOverlays(new Object());
```
## Example Override Result
It will still be fully tree shaken.
See the code in [rollup repl][2].
```js
const somethingElse = 'something else';
console.log(somethingElse);
// this will trigger loading of full overlays.js & override.js code
// console.log(overlays.list);
```
## Example Override Result Accessing
ONLY if you actually access `overlays` it will include `overlays.js` & `override.js`.
```js
class OverlayManager {}
let overlays = new OverlayManager();
function setOverlays(newOverlays) {
overlays = newOverlays;
}
const somethingElse = 'something else';
setOverlays(new Object());
console.log(somethingElse);
// this will trigger loading of full overlays.js & override.js code
console.log(overlays.list);
```
---
## Comprehensive Example
This time we have a separate controller which also accesses the `overlays`.
👉 `main.js`
```js
import { somethingElse, setOverlays, overlays } from './overlays.js';
import { OverlayController, somethingElse2 } from './OverlayController.js';
// the following code will tree shake overlays away hence overlays is side effect free
setOverlays(new Object());
console.log(somethingElse);
console.log(somethingElse2);
//** The following will toggle importing of overlays */
// 1. import overlays directly and access it
// console.log(overlays.list);
// 2. create an OverlayController which internally accesses overlays
// const ctrl = new OverlayController();
// console.log(ctrl.manager.list);
```
👉 `overlays.js`
```js
class OverlayManager {
constructor() {
this.list = [];
}
add(a) {
this.list.push(a);
}
}
export let overlays = new OverlayManager();
export function setOverlays(newOverlays) {
overlays = newOverlays;
}
export const somethingElse = 'something else';
// the following line is a side effect as it always will be included
console.log('overlays side effect');
```
👉 `OverlayController.js`
```js
import { overlays } from './overlays.js';
export class OverlayController {
constructor(config = {}, manager = overlays) {
this.manager = manager;
this.manager.add(this);
}
}
export const somethingElse2 = 'something else';
```
### Comprehensive Example Result
Even with all these intertwined code rollup can tree shake it fully away.
Again if you access the `overlays` or you start instantiating an `OverlaysController` it will include all the needed code.
Be sure to see it for yourself in the [rollup repl][3].
```js
const somethingElse = 'something else';
// the following line is a side effect as it always will be included
console.log('overlays side effect');
const somethingElse2 = 'something else';
console.log(somethingElse);
console.log(somethingElse2);
//** The following will toggle importing of overlays */
// 1. import overlays directly and access it
// console.log(overlays.list);
// 2. create an OverlayController which internally accesses overlays
// const ctrl = new OverlayController();
// console.log(ctrl.manager.list);
```
[1]: https://rollupjs.org/repl/?version=2.10.2&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMCU3QiUyMHNvbWV0aGluZ0Vsc2UlMkMlMjBvdmVybGF5cyUyMCU3RCUyMGZyb20lMjAnLiUyRm92ZXJsYXlzLmpzJyUzQiU1Q24lNUNuY29uc29sZS5sb2coc29tZXRoaW5nRWxzZSklM0IlMjIlMkMlMjJpc0VudHJ5JTIyJTNBdHJ1ZSU3RCUyQyU3QiUyMm5hbWUlMjIlM0ElMjJvdmVybGF5cy5qcyUyMiUyQyUyMmNvZGUlMjIlM0ElMjJjbGFzcyUyME92ZXJsYXlNYW5hZ2VyJTIwJTdCJTdEJTVDbiU1Q25leHBvcnQlMjBsZXQlMjBvdmVybGF5cyUyMCUzRCUyMG5ldyUyME92ZXJsYXlNYW5hZ2VyKCklM0IlNUNuJTVDbmV4cG9ydCUyMGZ1bmN0aW9uJTIwc2V0T3ZlcmxheXMobmV3T3ZlcmxheXMpJTIwJTdCJTVDbiU1Q3RvdmVybGF5cyUyMCUzRCUyMG5ld092ZXJsYXlzJTNCJTVDbiU3RCU1Q24lNUNuZXhwb3J0JTIwY29uc3QlMjBzb21ldGhpbmdFbHNlJTIwJTNEJTIwJ3NvbWV0aGluZyUyMGVsc2UnJTNCJTIyJTdEJTVEJTJDJTIyb3B0aW9ucyUyMiUzQSU3QiUyMmZvcm1hdCUyMiUzQSUyMmVzJTIyJTJDJTIybmFtZSUyMiUzQSUyMm15QnVuZGxlJTIyJTJDJTIyYW1kJTIyJTNBJTdCJTIyaWQlMjIlM0ElMjIlMjIlN0QlMkMlMjJnbG9iYWxzJTIyJTNBJTdCJTdEJTdEJTJDJTIyZXhhbXBsZSUyMiUzQW51bGwlN0Q=
[2]: https://rollupjs.org/repl/?version=2.10.2&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMCU3QiUyMHNvbWV0aGluZ0Vsc2UlMkMlMjBvdmVybGF5cyUyMCU3RCUyMGZyb20lMjAnLiUyRm92ZXJsYXlzLmpzJyUzQiU1Q25pbXBvcnQlMjAnLiUyRm92ZXJyaWRlLmpzJyUzQiU1Q24lNUNuY29uc29sZS5sb2coc29tZXRoaW5nRWxzZSklM0IlNUNuJTVDbiUyRiUyRiUyMHRoaXMlMjB3aWxsJTIwdHJpZ2dlciUyMGxvYWRpbmclMjBvZiUyMGZ1bGwlMjBvdmVybGF5cy5qcyUyMCUyNiUyMG92ZXJyaWRlLmpzJTIwY29kZSU1Q24lMkYlMkYlMjBjb25zb2xlLmxvZyhvdmVybGF5cy5saXN0KSUzQiUyMiUyQyUyMmlzRW50cnklMjIlM0F0cnVlJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMm92ZXJsYXlzLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmNsYXNzJTIwT3ZlcmxheU1hbmFnZXIlMjAlN0IlN0QlNUNuJTVDbmV4cG9ydCUyMGxldCUyMG92ZXJsYXlzJTIwJTNEJTIwbmV3JTIwT3ZlcmxheU1hbmFnZXIoKSUzQiU1Q24lNUNuZXhwb3J0JTIwZnVuY3Rpb24lMjBzZXRPdmVybGF5cyhuZXdPdmVybGF5cyklMjAlN0IlNUNuJTVDdG92ZXJsYXlzJTIwJTNEJTIwbmV3T3ZlcmxheXMlM0IlNUNuJTdEJTVDbiU1Q25leHBvcnQlMjBjb25zdCUyMHNvbWV0aGluZ0Vsc2UlMjAlM0QlMjAnc29tZXRoaW5nJTIwZWxzZSclM0IlMjIlN0QlMkMlN0IlMjJuYW1lJTIyJTNBJTIyb3ZlcnJpZGUuanMlMjIlMkMlMjJjb2RlJTIyJTNBJTIyaW1wb3J0JTIwJTdCJTIwc2V0T3ZlcmxheXMlMjAlN0QlMjBmcm9tJTIwJy4lMkZvdmVybGF5cy5qcyclM0IlNUNuJTVDbnNldE92ZXJsYXlzKG5ldyUyME9iamVjdCgpKSUzQiUyMiU3RCU1RCUyQyUyMm9wdGlvbnMlMjIlM0ElN0IlMjJmb3JtYXQlMjIlM0ElMjJlcyUyMiUyQyUyMm5hbWUlMjIlM0ElMjJteUJ1bmRsZSUyMiUyQyUyMmFtZCUyMiUzQSU3QiUyMmlkJTIyJTNBJTIyJTIyJTdEJTJDJTIyZ2xvYmFscyUyMiUzQSU3QiU3RCU3RCUyQyUyMmV4YW1wbGUlMjIlM0FudWxsJTdE
[3]: https://rollupjs.org/repl/?version=2.10.2&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMCU3QiUyMHNvbWV0aGluZ0Vsc2UlMkMlMjBzZXRPdmVybGF5cyUyQyUyMG92ZXJsYXlzJTIwJTdEJTIwZnJvbSUyMCcuJTJGb3ZlcmxheXMuanMnJTNCJTVDbmltcG9ydCUyMCU3QiUyME92ZXJsYXlDb250cm9sbGVyJTJDJTIwc29tZXRoaW5nRWxzZTIlMjAlN0QlMjBmcm9tJTIwJy4lMkZPdmVybGF5Q29udHJvbGxlci5qcyclM0IlNUNuJTVDbiUyRiUyRiUyMHRoZSUyMGZvbGxvd2luZyUyMGNvZGUlMjB3aWxsJTIwdHJlZSUyMHNoYWtlJTIwb3ZlcmxheXMlMjBhd2F5JTIwaGVuY2UlMjBvdmVybGF5cyUyMGlzJTIwc2lkZSUyMGVmZmVjdCUyMGZyZWUlMjAlNUNuJTVDbnNldE92ZXJsYXlzKG5ldyUyME9iamVjdCgpKSUzQiU1Q25jb25zb2xlLmxvZyhzb21ldGhpbmdFbHNlKSUzQiU1Q25jb25zb2xlLmxvZyhzb21ldGhpbmdFbHNlMiklM0IlNUNuJTVDbiUyRiUyRioqJTIwVGhlJTIwZm9sbG93aW5nJTIwd2lsbCUyMHRvZ2dsZSUyMGltcG9ydGluZyUyMG9mJTIwb3ZlcmxheXMlMjAqJTJGJTVDbiU1Q24lMkYlMkYlMjAxLiUyMGltcG9ydCUyMG92ZXJsYXlzJTIwZGlyZWN0bHklMjBhbmQlMjBhY2Nlc3MlMjBpdCU1Q24lMkYlMkYlMjBjb25zb2xlLmxvZyhvdmVybGF5cy5saXN0KSUzQiUyMCU1Q24lNUNuJTJGJTJGJTIwMi4lMjBjcmVhdGUlMjBhbiUyME92ZXJsYXlDb250cm9sbGVyJTIwd2hpY2glMjBpbnRlcm5hbGx5JTIwYWNjZXNzZXMlMjBvdmVybGF5cyU1Q24lMkYlMkYlMjBjb25zdCUyMGN0cmwlMjAlM0QlMjBuZXclMjBPdmVybGF5Q29udHJvbGxlcigpJTNCJTVDbiUyRiUyRiUyMGNvbnNvbGUubG9nKGN0cmwubWFuYWdlci5saXN0KSUzQiU1Q24lNUNuJTIyJTJDJTIyaXNFbnRyeSUyMiUzQXRydWUlN0QlMkMlN0IlMjJuYW1lJTIyJTNBJTIyb3ZlcmxheXMuanMlMjIlMkMlMjJjb2RlJTIyJTNBJTIyY2xhc3MlMjBPdmVybGF5TWFuYWdlciUyMCU3QiU1Q24lNUN0Y29uc3RydWN0b3IoKSUyMCU3QiU1Q24lNUN0JTVDdHRoaXMubGlzdCUyMCUzRCUyMCU1QiU1RCUzQiU1Q24lNUN0JTdEJTVDbiUyMCUyMGFkZChhKSUyMCU3QiU1Q24lMjAlMjAlMjAlMjB0aGlzLmxpc3QucHVzaChhKSUzQiU1Q24lNUN0JTdEJTVDbiU3RCU1Q24lNUNuZXhwb3J0JTIwbGV0JTIwb3ZlcmxheXMlMjAlM0QlMjBuZXclMjBPdmVybGF5TWFuYWdlcigpJTNCJTVDbiU1Q25leHBvcnQlMjBmdW5jdGlvbiUyMHNldE92ZXJsYXlzKG5ld092ZXJsYXlzKSUyMCU3QiU1Q24lNUN0b3ZlcmxheXMlMjAlM0QlMjBuZXdPdmVybGF5cyUzQiU1Q24lN0QlNUNuJTVDbmV4cG9ydCUyMGNvbnN0JTIwc29tZXRoaW5nRWxzZSUyMCUzRCUyMCdzb21ldGhpbmclMjBlbHNlJyUzQiU1Q24lNUNuJTJGJTJGJTIwdGhlJTIwZm9sbG93aW5nJTIwbGluZSUyMGlzJTIwYSUyMHNpZGUlMjBlZmZlY3QlMjBhcyUyMGl0JTIwYWx3YXlzJTIwd2lsbCUyMGJlJTIwaW5jbHVkZWQlNUNuY29uc29sZS5sb2coJ292ZXJsYXlzJTIwc2lkZSUyMGVmZmVjdCcpJTNCJTIyJTJDJTIyaXNFbnRyeSUyMiUzQWZhbHNlJTdEJTJDJTdCJTIybmFtZSUyMiUzQSUyMk92ZXJsYXlDb250cm9sbGVyLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMCU3QiUyMG92ZXJsYXlzJTIwJTdEJTIwZnJvbSUyMCcuJTJGb3ZlcmxheXMuanMnJTNCJTVDbiU1Q25leHBvcnQlMjBjbGFzcyUyME92ZXJsYXlDb250cm9sbGVyJTIwJTdCJTVDbiUyMCUyMCUyMGNvbnN0cnVjdG9yKGNvbmZpZyUyMCUzRCUyMCU3QiU3RCUyQyUyMG1hbmFnZXIlMjAlM0QlMjBvdmVybGF5cyklMjAlN0IlNUNuJTIwJTIwJTIwJTIwJTIwdGhpcy5tYW5hZ2VyJTIwJTNEJTIwbWFuYWdlciUzQiU1Q24lNUN0JTVDdCUyMHRoaXMubWFuYWdlci5hZGQodGhpcyklM0IlNUNuJTVDdCUyMCU3RCU1Q24lN0QlNUNuJTVDbmV4cG9ydCUyMGNvbnN0JTIwc29tZXRoaW5nRWxzZTIlMjAlM0QlMjAnc29tZXRoaW5nJTIwZWxzZSclM0IlMjIlN0QlNUQlMkMlMjJvcHRpb25zJTIyJTNBJTdCJTIyZm9ybWF0JTIyJTNBJTIyZXMlMjIlMkMlMjJuYW1lJTIyJTNBJTIybXlCdW5kbGUlMjIlMkMlMjJhbWQlMjIlM0ElN0IlMjJpZCUyMiUzQSUyMiUyMiU3RCUyQyUyMmdsb2JhbHMlMjIlM0ElN0IlN0QlN0QlMkMlMjJleGFtcGxlJTIyJTNBbnVsbCU3RA==
[=> See Source <=](../../../../docs/docs/rationales/side-effects.md)
{
"name": "@lion/core",
"version": "0.17.0",
"version": "0.17.1",
"description": "Core functionality that is shared across all Lion Web Components",

@@ -42,3 +42,3 @@ "license": "MIT",

"lit-element": "~2.4.0",
"lit-html": "^1.3.0"
"lit-html": "^1.4.0"
},

@@ -45,0 +45,0 @@ "keywords": [

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc