A way to use editor in inline-only mode about scribe HOT 19 CLOSED

@mitar Have you tried this with the latest version, v0.1.6? We made a change in that version which applies the formatters with every DOM mutation. Theoretically, if you are using the latest version of the sanitizer plugin without the BR element whitelisted, this should work as you expect.

from scribe.

Perfect! It works now! Thanks.

The only issue I had was that some modules are defined by both scribe and scribe-plugin-sanitizer. In dist branch. Like lodash-modern/internals/isNative. If I load both files I get errors that modules are already defined.

from scribe.

Interesting, can you show the exact error you get + stack trace?

@OliverJAsh Hadn't thought of that, but duplicate minimised deps might conflict.

from scribe.

@theefer How come we’re not seeing this?

from scribe.

Our environment is a bit tricky. :-) We are using Meteor and have Scribe packaged for Meteor. Because you are using Bower we are using a custom implementation of define/require to make this work: https://github.com/apendua/require

It tries to be consistent with other implementations, but maybe this is an edge case. On the other hand, trying to define a module with same name twice is a valid error and probably should throw an error in any implementation. It does not?

Before, scribe-plugin-sanitizer really provided just the plugin in dist branch, not also other things.

from scribe.

See here:

• https://github.com/guardian/scribe/blob/dist/scribe.js#L482
• https://github.com/guardian/scribe-plugin-sanitizer/blob/dist/scribe-plugin-sanitizer.js#L141

So if I load both those files, I get conflicting definitions. How could any system know that those are in fact the same and not an error? I do think you should not be bundling lodash-modern with scribe-plugin-sanitizer.

from scribe.

@OliverJAsh Ah yes I forgot we also used the packaged versions of scribe and scribe plugins...

I assume it must be down to the AMD loader's implementation. Can't see any defined behaviour in the AMD spec... Would be interesting to see what other AMD loaders do in that case.

@mitar the reason why a subset of lodash-modern is now compiled in the sanitizer plugin is because in the new version of the plugin, the code depends on some functions of lodash-modern.

from scribe.

@mitar We’re using RequireJS which interestingly doesn’t seem to throw an error in this case. However I agree that it probably should be throwing…

This is an artefact of using the distributed versions instead of building from source on the consumer’s end. One solution is to use lodash instead of lodash-modern. We would require that the consumers loads the library so it is available on the window object, for use by Scribe and any of its plugins. Although this is how most other libraries in the front-end ecosystem deal with dependencies, this is not something we want to do because it sucks to have globals and throws all the ideas of dependency management and encapsulation out of the window.

I recommend building from source:

1. Download the source of Scribe and any plugins you wish to use with Bower using the Git URIs (e.g. [email protected]:guardian/scribe.git). You will need to do this because the release tags point to the distributed versions.
2. Run your app through an AMD optimizer (e.g. RequireJS). This will walk the dependency graph and identify any AMD modules that are common to both Scribe and any of its plugins, creating a bundled JavaScript file for your app with no duplication.

from scribe.

@mitar I see you’re already one step ahead of us: peerlibrary/peerlibrary#336 😄

from scribe.

@OliverJAsh It wouldn't have to be through globals, Scribe could depend on a "lodash" AMD module (omitted from the minimised Scribe) that the app using Scribe would need to provide and expose as "lodash" using the AMD/Require config "paths".

from scribe.

@theefer Hmm, OK. My concern then is that the version of lodash is implicit.

from scribe.

It would be as a global too. But yes, that's suboptimal of course.

I wonder if switching to ES6 modules would make it less easy for people to compile themselves...

from scribe.

@theefer We should definitely consider this when we get around to spiking that! Theoretically it’s just another step. The ES6 transpiler would output AMD source which could then be optimized.

from scribe.

Good point. Btw, https://github.com/plumberjs/plumber-traceur works, just not the source maps...

from scribe.

Huh. The issue for us is that we are using Meteor which at this early stages does not yet support complicated pipelines. This is why we are simply using dist branch. OK. We will then for now use a modified version of our loader which just makes a warning if there are duplicate definitions: peerlibrary/require@c419a4e

And at some other later point we will try to use source code directly.

from scribe.

@mitar Thanks for your input, interesting to hear your use case. We will keep it in mind. Let’s discuss in #111.

from scribe.

Maybe you should consider preparing dist versions of plugins, so users wouldn't need to provide dependencies like lodash by themselves?

from scribe.

@mbrnwsk That’s actually what we do right now.

Our convention across Scribe and all of its plugins is to keep the source on master and the distribution code on dist.

from scribe.

Now I see it, thank you!

from scribe.