There are more intricacies to removing cookies. If the cookie has a path or domain, you cannot just remove it by name. We should expand this function to also take a domain

For example, in some code I'm working on I had to remove a cookie created with this library by doing the following:

Cookie.create('BVBRANDID', null, -1, domain);

As I'm thinking about HTTP/2, I'm realizing that there will be broader applications for the ability to share dependencies across files: as we break large applications up into smaller files, those smaller files will likely have common dependencies (e.g. lodash). We'll need a way to load a dependency once, and share it across files.

The bazaarvoice/static-asset-service repo already does this for a very specific set of assets. I'd like to extract the require/define functionality of that repo to this one, and then have the static asset service repo consume the functionality provided here. A consumer of this new module might look like this:

var VERSION = '1.0.0';
var deps = require('bv-ui-core/dependencyManager');

var hosts = {
  // ...
};

module.exports = function (config) {
  var env = config.env || 'prod';
  var baseURL = config.baseUrl || ('https://' +
    (hosts[env] || hosts.prod) +
    '/common/static-assets/' +
    VERSION + '/');

  return deps({
    loader : config.loader,
    namespace : config.namespace
    makeURLs : function (assets) {
      return baseURL + encodeURIComponent(requests.sort().join('+')) + '.js'
    }
  });
};

A consumer module would be able to specify where and how to load assets; the bv-ui-core module would provide require and define and handle the bookkeeping: making sure that required assets had a way to define themselves, and that required assets would be resolved immediately if already defined.

https://dojotoolkit.org/reference-guide/1.7/dojo/body.html

var body = require('body');

var div = document.createElement('div');
body().appendChild(div)

We use this in Firebird. Once we (firebird) can use commonjs this will have been an easy win, but for the meantime I figure the rest of BV may want to use this.

The library should instead do something reasonable so that users have a chance to identify the problem:

1. Log to console
2. Offer some hook for reporting errors
3. Offer some wrapper for listeners to catch and report errors

It seems like we don't have a recommended logging module for front-end apps.

console.log is discouraged, but it would be convenient to have a module here that wrapped that behavior safely.

Summary

I'd like to port the domReady module from Scoutfile here to bv-ui-core.

Explanation

As of version 1.7.0, Scoutfile includes bv-ui-core as a dependency. We've ported most everything else over on an as-needed basis and domReady now fits that bill.

Projects using Scoutfile should be unaffected and projects using bv-ui-core and not Scoutfile gain access to this functionality.

Proposed Work

1. Add domReady module to bv-ui-core
2. Update Scoutfile to use bv-ui-core's version of domReady instead of its own domready dependency

Alternatives

Since this module just exposes the domready NPM module, projects using bv-ui-core and not Scoutfile could add that module as an additional dependency and go on their way.

Since we moved most everything else over though, I am proposing we stick with the pattern.

Per https://www.gov.uk/eu-eea, the following three countries are part of the EU / EEA:

• Republic of Cyprus (CY)
• Malta (MT)
• Liechtenstein (LI)

Because BV does not currently support these locales, this has not been a problem. However, it would behoove us to preemptively add those codes to the list of EU territories, in case we ever do add support for those locales.

My reading of the logger module is that it starts with a log level of 1, and then resets the log level to whatever is found in the _bvui_debug cookie, if anything.

For production, I want to start the logger with a default log level of 4 (OFF), but then defer to whatever is found in the _bvui_debug cookie. I don't see a way to do this with the current module: it seems that the default log level always starts at 1 (INFO). If my application sets a log level, it will override anything that was set in the cookie, making the cookie not very useful.

I'd propose that:

• The module start at a default level of OFF
• The setLogLevel method be changed:

setLogLevel: function (level, force) {
  logLevel = (!cookieObj.logLevel || force) ? 
    (level || Logger.LOG) : 
    cookieObj.logLevel;
  logger('log', [ 'Log level set to', logLevel ]);
}

This way, applications can set a log level, but the setting will defer to the level in the cookie, unless the force argument is true.

The ghooks module is great for this.

There exists an issue where certain work has lead to situations where a single CSS file is being requested multiple times. This creates unnecessary load delays.

I propose we add a new module to bv-ui-core that provides the ability to check whether or not the CSS is already loaded and, if not, load a file from a given URL (if it's already present, just return). Ideally, we would have something that could be used as the following:

import cssLoadChecker from 'bv-ui-core/lib/cssLoadChecker'

cssLoadChecker.checkAndLoadStyleSheet(namespace.cssUrl)
      .then( () => {
        // do something on success
      })
      .catch( (error) => {
        throw new Error('Error loading css: ' + error)
      })

Where cssLoadChecker.checkAndLoadStyleSheet(namespace.cssUrl) returns a promise that will be fulfilled upon loading/verifying the CSS file.

Verifying will be done by checking for the existence of a certain style (ie display: none) on an empty div that we add with class bv-verify-css-loaded (or could possibly take in the class to look for as a param).

Something like this already exists within Firebird and is useful in the work I'm currently doing, and most likely future work as well. I believe this to be a good reason to add it to the bv-ui-core repo.

This code was made to avoid a problem with IE executing scripts before they are added to the DOM.

We should investigate an alternative workaround because the existing one takes 100ms due to the setTimeout.

We need a better fetch polyfill. Something that does safer checks for the native window.fetch.

Pending the outcome of karma-runner/karma#1497 and codymikol/karma-webpack#63.