Giter Club home page Giter Club logo

pattern-library's Introduction

Pattern Library

CI/CD Status

Check out our Contribution File

Check out our Architecture File

Check out our Code of Conduct

Design Guidelines

Link to Styleguide

Communication

Use the following channels for different kinds of requests/reports:

  • Bug reports, small change requests, "wishes": Issues
  • Questions, requests for help, requests for product presentations, etc: Slack #patterns-lib-devs
  • Feature requests (Components, etc): Contact Webhub Team

What we deliver

We release self-contained plug-and-play web components based on the custom elements specification, derived from the lit-element base class (maintained by Google).

Pattern Library components are exported to npm with 2 types of build artifacts: /dist/index.js and /lib/index.* in ES2019.

Component versioning

Different versions of our web components can coexist on the same web page! Here you can read more about component versioning.

Released Components

lerna

Component Github Packages
AXA Accordion npm version
AXA Button npm version
AXA Carousel npm version
AXA Checkbox npm version
AXA Commercial Hero Banner npm version
AXA Container npm version
AXA Cookie Disclaimer npm version
AXA Datepicker npm version
AXA Dropdown npm version
AXA Fieldset npm version
AXA File Upload npm version
AXA Footer npm version
AXA Heading npm version
AXA Footer Small npm version
AXA Icon npm version
AXA Input File npm version
AXA Input Text npm version
AXA Link npm version
AXA Materials npm version
AXA Policy Features npm version
AXA Popup npm version
AXA Radio npm version
AXA Table npm version
AXA Table Sortable npm version
AXA Text npm version
AXA Textarea npm version
AXA Top Content Bar npm version
AXA Modal npm version
AXA Stepper npm version
AXA Testimonials npm version

Code of Conduct

We are dedicated to building a welcoming, diverse, and safe community. We expect everyone participating in the AXA community to read and accept our Code of Conduct

Version Control

This repository is a monorepo managed by Lerna. This means that all components are centrally managed here, even though we publish them to NPM as separate packages.

Commits

We are using Conventional Commits to automatically version the components and update their changelogs. Feel free to use a tool of your choice to generate these commits.

Example for a commit message

feat(button): add new color blue

Closes #ticket-1234

Example for a Changelog entry

# [16.3.0](https://github.com/axa-ch-webhub-cloud/pattern-library/compare/@axa-ch-webhub-cloud/[email protected]...@axa-ch-webhub-cloud/[email protected]) (2023-07-31)

### Features

- **materials:** update color ([b832830](https://github.com/axa-ch-webhub-cloud/pattern-library/commit/b83283048acb5594812d019e2523bb014d3fc509)), closes [#123456](https://github.com/axa-ch-webhub-cloud/pattern-library/issues/123456)

For more examples, especially with BREAKING CHANGES, have a look at the Conventional Commits Examples.

Pattern Library via community CDN

You can add any Pattern Library component via the community CDN jsdelivr. This is useful for Prototyping or experimenting or if you don't want to bother with a frontend stack. This works only native (no react support). Here an example on how to add the JS for <axa-button></axa-button>: <script src="https://cdn.jsdelivr.net/npm/@axa-ch/button@latest/dist/index.js"></script>

How do I get my (unit) tests to work when using Pattern Library components?

The problem

Unit-test frameworks like Jest run under the node environment, which is quite different from a browser. The most commonly used abstraction to mimic a minimal browser within node is jsdom. However, jsdom lacks crucial features such as Mutation Observer, Custom Elements and other browser APIs commonly needed by web components.

Solutions

So what are your options?

  • Insisting on jest, one option would be to use a better DOM emulation. Exchanging jsdom with happydom, we now have enough emulated browser features to test web components. The details are described here.
  • Instead of using jest, employ end-to-end (e2e) testing tools that control a real browser, e.g. Playwright, Cypress or Testcafe. Arguably this is a better match for UI-heavy apps anyway, because e2e tests are closer to a real user experience.
  • Use a lightweight mocking strategy. The idea is to mock pattern library components by a simple, traditional-HTML replacement such as a <div> or a <button>. Here is a code sketch using Jest that employs this strategy:
    All Pattern-Library React components are imported from this index.js.
    
    import createAXAButton from '@axa-ch-webhub-cloud/button/lib/index.react';
    import createAXADropdown from '@axa-ch-webhub-cloud/dropdown/lib/index.react';
    
    export const AXAButton = createAXAButton(createElement);
    export const AXADropdown = createAXADropdown(createElement);
    
    AXAButton.displayName = 'AXAButton';
    AXADropdown.displayName = 'AXADropdown';
    
    __mocks__/index.js
    
    export const AXAButton = (props) => {
    return <button {...props}>{props.children}</button>;
    };
    ...
    

Testing with Selenium, Testcafe and other UI testing tools

By default, pattern-library web components make use of ShadowDOM. To trigger interactions inside such web component you need to access the DOM via the ShadowRoot. Schematically, this works like this: UI Testtool -> Driver -> native DOM selector -> ShadowRoot -> querySelector

Here is a concrete example in Java using Selenium:

public WebElement expandRootElement(WebElement element, WebDriver driver) {
    WebElement ele = (WebElement) ((JavascriptExecutor) driver)
            .executeScript("return arguments[0].shadowRoot",element);
    return ele;
}

Calling this method gives you the ShadowRoot in your Selenium environment. Beware: when calling findElement on the return value of expandRootElement only the following selectors will work:

  • By.id
  • By.className
  • By.cssSelector

pattern-library's People

Contributors

01231 avatar amir-ag avatar axa-stefan-schablowski avatar ben-zahler avatar bozojovicic avatar cge avatar danyball avatar dependabot[bot] avatar donaldduck1337 avatar flexbox avatar freiloris avatar jackblackch avatar jan-capiak avatar last-of-the-arctic-vaulters avatar lucamele avatar marcwelz avatar marek-polak avatar mareklacoaxa avatar markus-walther avatar mkahead avatar pachj avatar pchr-srf avatar raphael-suter avatar raphaellueckl avatar salle18 avatar selinagahlinger avatar thomas-krueger-axa avatar urswiss avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pattern-library's Issues

Simple Publish Subscribe Intercom not working

So I just tried to add a simple pubsub library to enable intercom between components.

Unfortunately:

  • At the moment all our components code is bundled as separate modules!
  • This redundantly imports all modules and thus affects the scope of a each module being a new one for every used module within each component
  • this breaks simple intercom possibilities, because private vars within modules aren't shared with their redundant friends...

Reproducible bug can be found at this PR #24

Must have features

  • DOM Mutation agnostic
  • loose coupling
  • ideally it would work with bundle or redundant modules (though redundant modules are a bug)

Mention: I really want to say that I mentioned this culprit weeks ago, but wasn't believed...
Though I know that I'm very competent in my profession and I always look from a wide point of view at tasks, including various very different angles.

Mention 2: Indeed there is a possible workaround, by polluting the global window object like: window.__sharedVarAmongRedundantModules. But NO; the correct way is bundling/loading each module never more than once.

How to release not complete

Currently bumping the version does only that.

But the dist folder is tracked within git and should be rebuild.
Anything else?

$map must be a map

{ Error: argument $map of map-has-key($map, $key) must be a map

Backtrace:
node_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss:2, in function map_has_key
node_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss:2, in function get-colors
node_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss:10, in function get-color
node_modules/@axa-ch/patterns-library/src/components/a-link/mixins/_link.scss:16, in mixin link-color
node_modules/@axa-ch/patterns-library/src/components/m-header-main-navigation/index.scss:105
at options.error (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/node-sass/lib/index.js:291:26)
status: 1,
file: '/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss',
line: 2,
column: 11,
message: 'argument $map of map-has-key($map, $key) must be a map\n\nBacktrace:\n\tnode_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss:2, in function map_has_key\n\tnode_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss:2, in function get-colors\n\tnode_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss:10, in function get-color\n\tnode_modules/@axa-ch/patterns-library/src/components/a-link/mixins/_link.scss:16, in mixin link-color\n\tnode_modules/@axa-ch/patterns-library/src/components/m-header-main-navigation/index.scss:105',
formatted: 'Error: argument $map of map-has-key($map, $key) must be a map\n\n Backtrace:\n \tnode_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss:2, in function map_has_key\n \tnode_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss:2, in function get-colors\n \tnode_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss:10, in function get-color\n \tnode_modules/@axa-ch/patterns-library/src/components/a-link/mixins/_link.scss:16, in mixin link-color\n \tnode_modules/@axa-ch/patterns-library/src/components/m-header-main-navigation/index.scss:105\n on line 2 of node_modules/@axa-ch/patterns-library/src/styles/functions/_color-map.scss\n>> @if not map_has_key($color-map, $style) {\n ----------^\n' }

Add warning logs if dependencies are missing

Currently device-state is the only component which is implemented without an associated custom element.
Instead it's class a-device-state needs to be attached to an existing DOM node to be working(<body> recommended).
If somehow the consumer of the patterns-lib imports device-state but forgets to add the class to an existing DOM, it should log a Warning/Error to help fix the issue.

I think this is a generic issue, which should be taken into consideration for every component.

SCSS/CSS not optional

Error: File to read not found or unreadable: /Users/axawinterthur/dev/axa-ch_style-html-guide/src/components/o-deterministic-lifecycle/index.scss

Footer Links interaction not decoupled from web component

The interaction code needed for mobile and it's accordion menu is directly coded within axa-footer-links Web Component.
Instead it should be decoupled as a separate class with various bindings to Web component, React, Angular, even jQuery

How wil we document those components

Each component has some intrinsic features and behaviours.
In special cases or in combination with certain other components it's likely that layout, measurements and other stuff may change.

Concrete examples are the mobile menu (which triggers an unrelated DOM tree from within another component) or the various variations of the footer.

Those intrinsic features and behaviours are reflected by code, either as html, in css or through js. So I don't think that we need to document the related stuff in all code, but we need to find an easy way to do it and make it parseable.

Regarding JS i would use awesome @JSdoc doclets.
And for SCSS I would use awesome @sassdoc doclets

clean header sub navigation

Currently the sub navigation data format is a bit foggy.

  • subMenuIndexSettings shouldn't be needed, better inherit from parent.
  • boxes, column seems suboptimal, I guess it's rather columns and links

Should we use proposed Custom Element

Due to different limitations and not standardised specs, should we keep investing in the Web-Components Custom Element or should we use only already standardised technology. Matter of the topic is about being fully standard or use experimental technology. Other frameworks, comparison between Web-Components and React are out of topic here as they don't move in direction of the main objective of the Style-Guide.

Objective: Create a Guide in HTML/CSS that is perfectly working and Semantically correct with some components that can be used within every framework

Module build failed: Error: Unknown plugin "external-helpers"

I'm currently migrating the footer in axa.ch repo and face this bug.
So I just installed it locally into the aem repo, though we should document this some how.

ERROR in ./~/@axa-ch/patterns-library/src/components/m-footer-links/js/footer-links.js
[scripts:watch] Module build failed: Error: Unknown plugin "external-helpers" specified in "/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/@axa-ch/patterns-library/.babelrc" at 0, attempted to resolve relative to "/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/@axa-ch/patterns-library"
[scripts:watch] ReferenceError: Unknown plugin "external-helpers" specified in "/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/@axa-ch/patterns-library/.babelrc" at 0, attempted to resolve relative to "/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/@axa-ch/patterns-library"
[scripts:watch] at /Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/options/option-manager.js:180:17
[scripts:watch] at Array.map (native)
[scripts:watch] at Function.normalisePlugins (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/options/option-manager.js:158:20)
[scripts:watch] at OptionManager.mergeOptions (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:36)
[scripts:watch] at OptionManager.init (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/options/option-manager.js:368:12)
[scripts:watch] at File.initOptions (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/index.js:216:65)
[scripts:watch] at new File (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/index.js:139:24)
[scripts:watch] at Pipeline.transform (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/pipeline.js:46:16)
[scripts:watch] at transpile (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-loader/lib/index.js:46:20)
[scripts:watch] at /Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-loader/lib/fs-cache.js:79:18
[scripts:watch] at /Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/happypack/lib/HappyLoader.js:46:23
[scripts:watch] at Object.Thread::0:1 (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/happypack/lib/HappyPlugin.js:321:7)
[scripts:watch] at ChildProcess.acceptMessageFromWorker (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/happypack/lib/HappyThread.js:66:32)
[scripts:watch] at emitTwo (events.js:105:20)
[scripts:watch] at ChildProcess.emit (events.js:185:7)
[scripts:watch] at handleMessage (internal/child_process.js:718:10)
[scripts:watch] at Pipe.channel.onread (internal/child_process.js:444:11)
[scripts:watch] @ ./src/js/redesign/footer-links.binding.js 7:19-100
[scripts:watch]

[scripts:watch] ERROR in ./~/@axa-ch/patterns-library/src/components/a-device-state/js/device-state.js
[scripts:watch] Module build failed: Error: Unknown plugin "external-helpers" specified in "/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/@axa-ch/patterns-library/.babelrc" at 0, attempted to resolve relative to "/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/@axa-ch/patterns-library"
[scripts:watch] ReferenceError: Unknown plugin "external-helpers" specified in "/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/@axa-ch/patterns-library/.babelrc" at 0, attempted to resolve relative to "/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/@axa-ch/patterns-library"
[scripts:watch] at /Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/options/option-manager.js:180:17
[scripts:watch] at Array.map (native)
[scripts:watch] at Function.normalisePlugins (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/options/option-manager.js:158:20)
[scripts:watch] at OptionManager.mergeOptions (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/options/option-manager.js:234:36)
[scripts:watch] at OptionManager.init (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/options/option-manager.js:368:12)
[scripts:watch] at File.initOptions (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/index.js:216:65)
[scripts:watch] at new File (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/file/index.js:139:24)
[scripts:watch] at Pipeline.transform (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-core/lib/transformation/pipeline.js:46:16)
[scripts:watch] at transpile (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-loader/lib/index.js:46:20)
[scripts:watch] at /Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/babel-loader/lib/fs-cache.js:79:18
[scripts:watch] at /Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/happypack/lib/HappyLoader.js:46:23
[scripts:watch] at Object.Thread::1:1 (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/happypack/lib/HappyPlugin.js:321:7)
[scripts:watch] at ChildProcess.acceptMessageFromWorker (/Users/axawinterthur/dev/aem-all_ext/frontend-lib/node_modules/happypack/lib/HappyThread.js:66:32)
[scripts:watch] at emitTwo (events.js:105:20)
[scripts:watch] at ChildProcess.emit (events.js:185:7)
[scripts:watch] at handleMessage (internal/child_process.js:718:10)
[scripts:watch] at Pipe.channel.onread (internal/child_process.js:444:11)
[scripts:watch] @ ./src/js/redesign/device-state.binding.js 7:19-100

Button animation sometimes slow

Sometimes I randomly observed a very slow button animation.
Guess the animation should be moved to hardware acceleration enabled motion.

Let‘s move away from web components

Let‘s discuss with the all the frontend guys/girls if it‘s still a good practice to build webcomponents, since we have now a more clear sight who is using which framework and what the trend shows for axa switzerland. The new disussions with multiple teams shows a trend from moving away from angular to react. Let‘s discuss this since we are facing multiple problems with webcomponents... and they are not as simple to use in an other franework as thought.

add sticky container

The header should be sticky but only on mobile.

Requirements:

Like:

<axa-sticky-container>
  <axa-sticky>...</axa-sticky>

  <axa-sticky>...</axa-sticky>
</axa-sticky-container>

contextual communication between components

After I quickly fixed #26 (publish/subscribe) I see the possible use case of a list of child components who need to communicate between each other within a specific context.

<axa-context>
  <axa-foo></axa-foo>
  <axa-bar></axa-bar>
</axa-context>

<axa-context>
  <axa-foo></axa-foo>
  <axa-bar></axa-bar>
</axa-context>

With a small hack this can be archived currently using incremental channels, like:

let n = 0;
publish(`channel-${n}/change`, ...)
subscribe(`channel-${n}/change`, ...)

...
++n;
publish(`channel-${n}/change`, ...)
subscribe(`channel-${n}/change`, ...)

Requirements

  • enable intercommunication between hierarchy-agnostic components
  • opt-in to select kind of context
  • pass contextual data down

Implement common module. Activate ES Modules in pkg.module prop and IFEE modules that global namespace

ATM we bundle up isolated bundle which include identical modules redundantly.

This breaks access to local variables between same module instances.

// this variable is scope within each redundant import/bundle of this module
// and not accessible to other instances of this same module
const localVar = {}

export function foo() {
  localVar.key = 'value';
}

export function bar() {
  return localVar.key;
}

Webcomponents randomly not rendered

Somehow importing our custom Web Components into Chrome by HTML Imports randomly triggers a weird bug in Chrome, which results in rendering the component in one place but not in another.

Switching to pure ESnext based import's seems to make Firefox some troubles #25 :

TypeError: window.customElements is undefined

This bug isn't reasonable and needs to be 1000% fixed.

Todo

  • Make 1000% sure to understand the cause of this bug - no guessing. Ideally easily observable by failing test.
  • order of components lifecycle has to be deterministic
  • Report this bug to Chrome's issue tracker and link it's issue here
  • find reliable cross-browser, testable workaround / bugfix
  • document above solution, and communicate it to everyone involved
  • make sure that every single web component can be reliable rendered in all supported browsers

state classes are constantly repeating

I periodically utilize generic state classes like is-open, is-active, etc.

So I'm concerned what if 2 separate components utilize the same state class and are being nested within each other. This could lead to wrong states triggering false CSS properties.

Hence I propose to namespace even state classes by the components name in the format of is-component-state, like: is-dropdown-open.

Header molecules naming

I'm just curious, wouldn't it make sense to prefix header related/only components by header-, so it's more clear where to use them, like:

from to or even
m-top-content-bar m-header-top-content-bar m-header-top
m-meta-navigation m-header-meta-navigation m-header-meta
m-meta-navigation-mobile m-header-meta-navigation-mobile m-header-meta-mobile
m-main-navigation m-header-main-navigation m-header-main
m-main-navigation-mobile m-header-main-navigation-mobile m-header-main-mobile
m-sub-navigation m-header-sub-navigation m-header-sub

We could even drop the -navigation part, cause it's redundant and isn't always meant for navigation only...

is mobile click delay really fixed through CSS?

According to BS4 reboot:

Traditionally, browsers on touchscreen devices have a delay of approximately 300ms between the end of a “tap” – the moment when a finger/stylus is lifted from screen – and the click event being fired. This delay is necessary for these browsers to correctly handle “double-tap to zoom” gestures without prematurely triggering actions or links after the first “tap”, but it can make your site feel slightly sluggish and unresponsive.

Most mobile browsers automatically optimize away this 300ms delay for sites that use the width=device-width property as part of their responsive meta tag (as well as for sites that disable zooming, for instance with user-scalable=no, though this practice is strongly discouraged for accessibility and usability reasons). The biggest exceptions here are IE11 on Windows Phone 8.1, and iOS Safari (and any other iOS WebView-based browser) prior to iOS 9.3.

On touch-enabled laptop/desktop devices, IE11 and Microsoft Edge are currently the only browsers with “double-tap to zoom” functionality. As the responsive meta tag is ignored by all desktop browsers, using width=device-width will have no effect on the 300ms delay here.

To address this problem in IE11 and Microsoft Edge on desktop, as well as IE11 on Windows Phone 8.1, Bootstrap explicitly uses the touch-action:manipulation CSS property on all interactive elements (such as buttons and links). This property essentially disables double-tap functionality on those elements, eliminating the 300ms delay.

In the case of old iOS versions (prior to 9.3), the suggested approach is to use additional scripts such as FastClick to explicitly work around the delay.

For further details, see the compatibility table for suppressing 300ms delay for touchscreen interactions.

finish checkbox and radio

The checkbox and the radio input element are not finished yet.

Todo: Needs an input and a label. They should be connected. WC are only used as holders so we need the input element

ELIFECYCLE error

try running either of bump scripts like npm run bump-major-beta results in:

@axa-ch/[email protected] prebump-major-beta /Users/axawinterthur/dev/axa-ch_style-html-guide
test
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @axa-ch/[email protected] prebump-major-beta: test
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @axa-ch/[email protected] prebump-major-beta script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /Users/axawinterthur/.npm/_logs/2017-12-13T16_43_48_507Z-debug.log

Deploy to gh pages

Would be nice to have a gh page deployment to be able to explore the lib

Keep existing css classes

If a custom component has some classes attached to it, then they should be kept and not thrown away.

Edit:

<axa-custom class="any-classes-here"></axa-custom>
Custom extends HTMLElement {
  connectedCallback() {
    // remove all classes, in above case: .any-classes-here
    this.className = 'a-custom';
  }
}

window.customElements.define('axa-custom', Custom);

Results in:

<axa-custom class="a-custom"></axa-custom>

Fonts Slow Network is detected

Chrome dev tools log:

Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff
index.js:925 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff2
index.js:925 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff
index.js:925 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff2
index.js:925 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff
index.js:925 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff2
index.js:925 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff
index.js:925 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff2
index.js:925 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff
index.js:1781 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff2
index.js:1781 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff
index.js:1781 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff2
index.js:1781 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff
index.js:1781 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff2
index.js:1781 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff
index.js:1781 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff2
index.js:1781 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff
Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-regular.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-700.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/source-sans-pro-v10-latin-600.woff
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff2
:3000/#o-header:1 Slow network is detected. Fallback font will be used while loading: http://localhost:3000/assets/fonts/PublicoHeadline-Bold-Web.woff

define integration policy

To ease development and keep quality high we should define and stick to an integration policy.

I recommend:

  • establishing a develop branch
  • prevent merges in case of failing linters or tests (can be setup by travis, appveyor, you name it)
  • fast-forward merges only into master
  • versioning strategy (semver)
  • deprecation warning (static analysis vs runtime analysis)

Hierachical Webcomponents Lifecycle order is not deterministic

Edit:
~~Markup should determine hierarchical components bootstrap order, but it doesn't!~~~
The spec allows to bootstrap components as they are defined, independent of the markup's structure. Though in the following case I need this order to be deterministic in sense of markup structure, not definition order.

Given following example I expect:

<axa-parent>
  <axa-child></axa-child>
</axa-parent>

Expected:

Parent -> constructor
Parent > connectedCallback
Child -> constructor
Child > connectedCallback

Instead the definition of a web-component dictates the order of it's bootstrapping process.
Observed:

index.js:579 Child -> constructor
index.js:588 Child > connectedCallback
index.js:542 Parent -> constructor
index.js:551 Parent > connectedCallback

screen shot 2017-12-06 at 14 06 04

device state should trigger initially

Since we switched component initialisation to DOMContentLoaded, the device-state/change event doesn't trigger anymore after the component was initialised (cause this initial trigger is itself also triggered by DOMContentLoaded).

Thus just fire always an initial event on subscription, if possible 🎉

Well, that's not so easy because of redundant modules.
So it seems it's time to start attaching data to DOM...

Or just provide a static getDeviceState function which needs to be used for initial value retrieval

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.