springload / wagtaildraftail Goto Github PK

The keyboard shortcuts work perfectly though!

For this to be a pleasant editing experience, we need the styling of the editor to be aligned with that of Wagtail. I don't want to tie Draftail to Wagtail too much, so IMHO the styles (and UI configuration) should live in here, while Draftail simply makes the style/UI configurable and themable.

See springload/draftail#63

I am running the wagtaildraftail test environment locally and playing around online at: https://springload.github.io/draftail/
Maybe I am bit of a n00b on this matter but I'm having some difficulty in pinpointing what T&C actually does. Is there a better naming for this UX-wise?

Could we use the same |richtext as Wagtail instead? Abuse / extend its existing behavior or override it? Is this possible / recommandable?

It looks like git release vx.y.z requires some dependency? I got git: 'release' is not a git command.

Also, make publish fails:

$ make publish
dist
make: dist: No such file or directory
make: *** [publish] Error 1

Could be a good announcement blog post too!

Linked from the README, likely on Heroku, ideally without an admin login –– or with a login, but with a daily auto-reset? What is the best practice?

To investigate for potential auto-reset – deployments with Travis on push to master + Travis cron https://docs.travis-ci.com/user/cron-jobs/

Edit: could be running the test site's code?

This causes collectstatic to miss the required js and css since it cannot find the static dir for the app, and the assets don't get deployed.

Required for rolling out via a package manager.

Now that it is merged into Wagtail 2.0, there's little point in updating this package compatibility. Instead, provide an upgrade path since since are handled a bit differently.

See screencast:

Currently, the default value is an empty dict which is basically an invalid content state. Therefore, the editor should return None which clearly state the lack of content.

• Update springload/draftail package.
• Update springload/draftjs_exporter package.
• Update springload/draftail dependency for this package.
• Update springload/draftjs_exporter dependency for this package.
• Update block accordingly
• Update field accordingly (actually the field doesn't have a default value atm?)
• Remove the now useless form field and validator?

The error is quite cryptic: Failed: cov_15u4dh72x3 is not defined. This is only when code coverage is measured, so I imagine there is some interference between istanbul, the Babel transpilation of async/await, and Electron. Maybe Istanbul doesn't realise what parts of code are actually ran in Electron.

Just like you can use a RichTextField/RichTextBlock in Wagtail (powered by hallo) without the need to configure it, wagtaildraftail should ship with proper defaults (all the default entities, blocks and styles in the editor and the corresponding exporter config).

For the exporter, everything can happen in wagtaildraftail.utils.get_exporter_config.

For the editor, this might be a bit more complex. If a widget doesn't not receive any options upon initialisation, we could add some defaults, but for the widget to be instantiated in the first place, it needs to be present in the WAGTAILADMIN_RICH_TEXT_EDITORS settings (which is used by wagtail.wagtailadmin.rich_text.get_rich_text_editor_widget which both our field and block use to load the widget). I'm not too keen to hijack the settings to inject ours, so maybe we could have a intermediary utility function which first try to load "the Wagtail way", but failing that (catch KeyErrors) would return our default widget.

So it's more consistent, and people can see the "real" running code

Django 1.10 (and earlier) makes an invocation of the widget.render method passing arguments using positional propagation: https://github.com/django/django/blob/1.10.7/django/forms/boundfield.py#L101

force_text(widget.render(name, self.value(), attrs=attrs))

Django 1.11 (and later) changes this invocation so that arguments bound to names:
https://github.com/django/django/blob/1.11/django/forms/boundfield.py#L116

html = widget.render(
        name=name,
        value=self.value(),
        attrs=attrs,
        **kwargs
    )

This implies that from now onwards the attribute names are significant.

Also, there was a new attribute introduced: renderer, which becomes mandatory since django 2.1

Following similar developments in our client work,

DRAFT_ENTITY_TYPE_DOCUMENT = {
    'label': 'Document',
    'type': ENTITY_TYPES.DOCUMENT,
    'source': 'DocumentSource',
    'decorator': 'Document',
    'icon': 'icon-doc-full',
}

import LinkSource from './LinkSource';
import ImageSource from './ImageSource';
import DocumentSource from './DocumentSource';
import ModelSource from './ModelSource';
import EmbedSource from './EmbedSource';

/**
 * Mapping object from name to component.
 */
export default {
    LinkSource,
    ImageSource,
    DocumentSource,
    ModelSource,
    EmbedSource,
};

See springload/draftail#85. Until there is a new API there, those two sources need to either:

• Bail out of the entity adding workflow if the selection is collapsed.
• Insert the text the entity is to be applied upon, and the entity.

I like option 2 better because it's closer to the behavior of other editors, and the text can always be edited / reverted afterwards. For links, we could go with the the page title for pages, and full URL (external or email links). For documents, the document title seems like a good link text.

At the moment the package comes with a pre-compiled bundle that can be integrated as a single script tag. This is problematic because some of Draftail still requires JS code to be written for configuration.

Figure out how to expose this properly (npm package of the same name?) so it can be consumed and customised fully.

This is just a matter of test setup. The problems are:

• E2E tests fail when code coverage is recorded, so test coverage needs to exclude them
• E2E tests require the server to be started (make start), but they are also used in git hooks where the server would already be started. We need to branch this off.

I think the likely best move would be to orchestrate this with tox / bash scripts, and only run it with different environments in git hooks / CI.

Wagtail 1.12 will introduce Rich Text Features (see wagtail/wagtail#3736), a way to configure the features (format, heading, etc) of a rich-text editor per field. The underlying goal is to the editor config (which is kinda global, i.e. config for the whole Draftail editor) and the features of a given field (i.e. allowing different formatting options for the intro and body blocks). Eventually, features will also be hooked with whitelisting and text conversion logic (the ultimate goal of having all rich text editor saving content in a uniform way to avoid editor lock-in (I can't find the discussion around that anymore sorry)).

I'm not sure whether it's too early to start implementing such thing, but we should at least think of it as it might shuffle quite a few things.

The two current decorators define the following boilerplate as their strategy:

export function findDocumentEntities(contentBlock, callback) {
  contentBlock.findEntityRanges((character) => {
    const entityKey = character.getEntity();
    return entityKey !== null && Entity.get(entityKey).getType() === ENTITY_TYPE.DOCUMENT;
  }, callback);
}

This is boilerplate-y enough that it should be the default behavior of Draftail – if no custom strategy is defined, use the following code with the entity's type. Note that this has to be implemented in Draftail first, then used in here. Would also save us from having to write complex tests of this behavior here.

See screenshot, missing margin.

I haven't seen this in our own projects so I imagine we have some style somewhere for this 🕵️ .

How to reproduce:

1. write a sentence
2. press Shift+Alt+Left
3. press Link button
4. choose a link
5. see that the text is not highlighted anymore
6. press Enter
7. newline symbol overwrote the link sentence

• Do they need a DB?
• Add test-watch command. The one in draftjs_exporter is based on nodemon. Perhaps there is a more sanctified way to do this with Django tests.
• Prevent fast failure – we want to see all the fails in the test suite.
• Get rid of that big useless stack trace.

... so it's easier to integrate into existing sites.

Note that we likely won't get to 100% parity with Hallo – up to us to figure out how close this has to get.

Start defining how to do it, then think of whether to develop it ourselves or not. Two paths:

• Let the JS handle this, with one of the other exporters available on https://github.com/nikgraf/awesome-draft-js
• Let draftjs_exporter do it, by configuring it differently.

See screencast. I haven't been able to establish a pattern!

TL;DR: Should we test against different Django/Wagtail versions in addition to different Python versions?

52176e1 add a fix for Django >= 1.8 so it would make sense for this package to be tested against different versions of Django (and Wagtail eventually).

Looking at what Wagtail does (.travis.yml and tox.ini), they only test for Django 1.8 with Python 2.7 and test with Django 1.10 and 1.11 on all other Python versions. I imagine this is because the those are the version they have branches for in the code (just like our commit above), although it's not clear why they don't test 1.10 with Python 2.7 given it is officially supported by Django.

Regarding Wagtail, the test app has been build for 1.9 and looking at the code, should work with previous versions, although we might want to be careful.

FWIW, I'm experimenting with such config on chore/ci-config.

from django.utils.encoding import force_text

It is possible to configure style_map with draftjs_exporter but wagtaildraftail doesn't forward it (it only pass entity_decorators, composite_decorators and block_map through).