Block arrow key navigation

[ellatrix]

WIP. Does not set caret at start or end based on the direction yet.

[ellatrix]

See #520.

[ellatrix]

These are issues where I think it would make much more sense to have a contentEditable container for the whole editor... Having that doesn't imply any fragility btw, if special keys etc. are moved to reducers. (See Draft.js too). Fragility around nested editable fields can easily be solved by taking the attribute away: take it away from the root and add to the nested field on focus, add back to the root and take away from the nested field on blur.

Anyway, this seems a fine temporary solution.

[ellatrix]

Hm, there's also an issue with the link boundary stuff adding a zero width space so that the caret is not at the start or end.

[youknowriad]

I would prefer to avoid the imperative approach here and rely on the redux flow for focusing the target. something like:

const blockUid = targetNode.closest( '[data-block-uid]' ).attr( 'data-block-uid' );
const editable = targetNode.closest( '[data-block-editable]' ).attr( 'data-block-editable' );
const offset = before ? -1 : 0;
onFocus( blockUid, { editable, offset } );

This assumes we add the data-block-uid to each block container and a data-block-editable (optional) to blocks with multiple editables.

(I'm secretly hoping we could use these attributes to drop the focus, updateFocus and mergeWithPrevious completely from the block edit function.)

@aduth Thoughts

[aduth]

I like the idea of dispatching to Redux to shift focus, and the idea to eliminate focus props from the edit implementation. I'm not so sure of assuming attributes on an ancestor node and using them as action properties. But I've not digested this deeply and don't have alternatives to suggest at the moment.

[jasmussen]

With #520 closed, perhaps we should close this also?