These are chat archives for ractivejs/ractive

24th
Feb 2018
Joseph
@fskreuz
Feb 24 2018 19:06
So UMD exports CJS, AMD and global. Ractive plugins normally self-register to the global registry when used as scripts. What prevents me from manually attaching it and not messing with the UMD headers?
import Ractive from '@ractivejs/core'

export const modelAdaptor = {...}
export const collectionAdaptor = {...}

Ractive.adaptors.AmpersandModelAdaptor = modelAdaptor
Ractive.adaptors.AmpersandCollectionAdaptor = collectionAdaptor
Bundled, it looks like this:
(function (global, factory) {
    typeof exports === 'object' && typeof module !== 'undefined' ? factory(exports, require('@ractivejs/core')) :
    typeof define === 'function' && define.amd ? define(['exports', '@ractivejs/core'], factory) :
    (factory((global['@ractivejs/adaptor-ampersand'] = {}),global.Ractive));
}(this, (function (exports,Ractive) { 'use strict';

var modelAdaptor = {...};

var collectionAdaptor = {...};

Ractive.adaptors.AmpersandModelAdaptor = modelAdaptor;
Ractive.adaptors.AmpersandCollectionAdaptor = collectionAdaptor;

exports.modelAdaptor = modelAdaptor;
exports.collectionAdaptor = collectionAdaptor;

})));
Am I missing something? I remember a conversation about fiddling with the UMD headers because of this, but I don't remember why exactly.
Paul Maly
@PaulMaly_twitter
Feb 24 2018 19:10
I think we don’t need to import Ractive there
Chris Reeves
@evs-chris
Feb 24 2018 19:14
I think the issue is that sometimes you want to import ractive and sometimes you want to use the global
depending on how the script is run
my solution was to use a query param on the script tag including the component to handle self registration on global Ractive
Joseph
@fskreuz
Feb 24 2018 19:18
Oh, I see what you mean. If it's used as a module, then you don't want it on the global.
Was looking at it from the module side, i.e. "what if I also wanted it on the global?"
Chris Reeves
@evs-chris
Feb 24 2018 19:19
so <script src="//some.cdn/ractive-plugin-superfly.js?register=SuperFly></script> will automatically register the component as SuperFly in whatever registry is appropriate, and leaving off the name would use the plugin default
I may have to reconsider that a bit to work with use, which should make everything a bit easier
wouldn't require the name, because use plugins provide defaults (that may not be override-able, depending on the author)
Joseph
@fskreuz
Feb 24 2018 19:21
Rollup clearly wasn't really designed for this use case :grin:
Chris Reeves
@evs-chris
Feb 24 2018 19:22
I've been using a common util module to handle that in my stuff
Paul Maly
@PaulMaly_twitter
Feb 24 2018 19:25
In Webpack we have “library” and “libraryTarget” options. So, plugin can just export global thing, like ‘’RactiveAmpersandAdaptor’’ or something
Joseph
@fskreuz
Feb 24 2018 19:27
UMD is totally fine. Was just wondering if I could avoid this sorcery when using the plugin UMDs as plain scripts.
    var r = new Ractive({
      transitions: {
        fade: window['@ractivejs/transition-fade'].fade,
        fly: window['@ractivejs/transition-fly'].fly,
        scale: window['@ractivejs/transition-scale'].scale,
        slide: window['@ractivejs/transition-slide'].slide,
        typewriter: window['@ractivejs/transition-typewriter'].typewriter
      }
    });
This uses out-of-the-box UMD and plain HTML so... sorcery. :grin:
Not so pretty when you use the package name as global. It's very well namespaced tho. :joy:
Chris Reeves
@evs-chris
Feb 24 2018 19:31
🤣😂😅😥
Joseph
@fskreuz
Feb 24 2018 19:34
@PaulMaly_twitter yep, build tools have ways to map a module import to a global. It's the plain script use case that's going to be weird.
Joseph
@fskreuz
Feb 24 2018 19:41
In other things, is there a way to do browser testing that 1) doesn't require a ton of config and 2) doesn't use Karma?
Something like "run cli command... spawns browser in background... here's my library... just run my qunit tests... TAP results."?
Something like QUnit's official cli, but runs on a headless browser not node.
Most of the fancy unit test tools out there are either node-only, or use jsdom - not a good way to test the browser-worthiness of some code.
Chris Reeves
@evs-chris
Feb 24 2018 19:48
nothing jumps out, but it looks like a qunit CLI that targets headless chrome wouldn't be too difficult to write
Paul Maly
@PaulMaly_twitter
Feb 24 2018 22:00
@fskreuz maybe ‘’use()’’ solves this problems?
You don’t need to import Ractive to your plugin anymore