Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

@layerhq/web-xdk

Package Overview
Dependencies
Maintainers
27
Versions
37
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

@layerhq/web-xdk

The Layer eXperience SDK for Web provides a library for talking to Layer Services, and a library of widgets to simplify adding chat capabilities into your application.

  • 4.0.6
  • latest
  • Source
  • npm
  • Socket score

Version published
Weekly downloads
7
increased by75%
Maintainers
27
Weekly downloads
 
Created
Source

Layer Web eXperience Development Kit

Browser Support Matrix:

BrowserVersionOS Tested Against
Internet Explorer11.0Windows 8.1
Edge16.0Windows 10
Edge13.0Windows 10
Safari11.0OSX 10.13
Safari10.0OSX 10.12
Safari (IOS)defaultIOS 11.1
Safari (IOS)defaultIOS 10.0
Chrome55OSX 11.0
Chrome48Linux
Firefox58Windows 10
  • Older versions of Chrome should work but are not tested
  • Older versions of Firefox should work but currently fail unit tests due to how Jasmine 3.0.0 reports IndexedDB errors. While not officially supported, feel free to report issues on recent versions of Firefox.
  • Older versions of Safari do not support Websockets and will not be supported
  • Older versions of Edge are not supported
  • Older versions of IE are not supported

Introduction

The Layer Web XDK provides a library of widgets to simplify adding chat capabilities into your application.

It is implemented using the Webcomponents Polyfill; in particular, this project uses the "light" version of the polyfill which means we do not use Shadow Dom.

Why use the Layer XDK UI Components?

  1. It handles a lot of capabilities for you:
    • Sends read receipts on any message that has scrolled into view, and remained visible for 2.5s
    • Sends typing indicators to other participants
    • Renders typing indicators from other participants
    • Pages your queries as the user scrolls
    • Handles a variety of common text processing tasks (emoticons for example), and provides plugins for adding more
    • Handles a variety of Message Types and provides plugins for adding more
  2. It is highly customizable
    • You may replace a stylesheet for a given widget with your own stylesheet
    • You may replace the HTML Template for a given widget with your own template
    • You may replace an entire widget class with your own definition of that class

Installation

CDN

<script src='https://cdn.layer.com/xdk/4.0.0/layer-xdk.min.js'></script>
<link rel='stylesheet' href='https://cdn.layer.com/xdk/4.0.0/themes/layer-basic-blue.css' />
<script>
var client = window.Layer.init({
  appId: 'layer:///apps/staging/UUID'
});
</script>

NPM

npm install @layerhq/web-xdk --save
var Layer = require('layer-xdk');
const client = Layer.init({
  appId: 'layer:///apps/staging/UUID'
});
<link rel='stylesheet' href='node_modules/xdk/themes/build/layer-basic-blue.css' />

If using npm link, note that after cloning this repo, run:

  1. npm install
  2. grunt prepublish
  3. cd npm
  4. npm link .

Build Commands

  • grunt develop: Starts a webserver for running tests or sample apps, and watches for changes, rebuilding source and theme on any change
  • grunt docs: Generate API Reference docs into folder ~/docs; you may need to run gem install jsduck first. Warning: Use Ruby 2.0; later versions log too many errors.
  • grunt theme: Generate CSS files from the .less files
  • grunt debug: Generate all lib folders and basic build files.
  • grunt build: Run's grunt debug and grunt theme and then generates all minified files
  • grunt coverage: Generate a coverage test build; additional steps shown below for running a coverage test

Coverage Tests

To run coverage tests:

  1. grunt coverage will write test/coverage-build.js with an instrumented version of the build file
  2. Run tests on http://localhost:8004/test/CoverageRunner.html
  3. Open the javascript console and modify the test results with:
coverageResults = {};
Object.keys(__coverage__).forEach(key => {
    // Simplify reporting paths by taking 'lib' out of the path
    var newKey = key;

    // Many components have a path of components/component_name/component_name.js;
    // simplify reporting of paths to components/component_name.js
    newKey = newKey.replace(/components\/.*\//, "components/");
    var parts = newKey.split(/\//);
    if (parts[parts.length-2] + '.js' == parts[parts.length-1]) {
        parts.splice(parts.length-2, 1);
        newKey = parts.join('/');
    } else if (newKey.match(/\/ui\/cards\/[^/]+\/[^/]+\.js$/)) {
      newKey = newKey.replace(/(\/ui\/cards\/)([^/]+\/)([^/]+\.js)$/, "$1$3");
      console.log("newKey: " + newKey);
    }
    coverageResults[newKey] = __coverage__[key];
})
  1. Copy the results with copy(JSON.stringify(coverageResults))
  2. Paste the results into coverage/coverage.json
  3. Run the report generation tool with istanbul report --root coverage --dir coverage/report html
  4. Open the report with open coverage/report/index.html

Future Work

  • This project does not use Shadow Dom due to performance implications of the Shadow Dom polyfill. The Shadow Dom API provides an ideal mechanism for passing subcomponents such as buttons for the composer, and other custom elements as inputs. Currently, this can only be done via dom manipulation; even in the case of ConversationPanel.composeButtons one must dom create elements, put them in an array and then set composeButtons to refer to them. This is especially bad in React. A better mechanism should be discussed, and implemented.
  • Inclusion of standard dom nodes that go between messages, such as Date headers, Headers indicating "read up to here", etc... For now we just include the capability to build your own.

Development Notes

JSDuck is used to document this system. Properties and Methods are flagged as public/protected/private according to rules somewhat different from standard:

  • Public: Part of the public API; Public methods whose names follow the form onXXX are not for calling publicly, but rather for customizing with mixins. They are public in the sense that they have been explicitly exposed for customization.
  • Protected: Any method that is not part of the Public API developers building apps would use, but which developers building custom Message Types would use are defined to be @protected. These will not always strictly follow rules for what it means to be Protected in Object Oriented terminology
  • Private: Any method that is neither intended as a public API, nor for developers building Custom Messages are treated as Private. They may in fact be accessed by other components, and are only Private in the sense that they are for internal framework use only.

Getting jsduck build to work:

  • It runs with ruby 2.0.0 than ruby 2.4
  • gem install jsduck

FAQs

Package last updated on 25 Sep 2018

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

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