Expose (most) transactions

[remko]

Resolves #187

Exposes all transactions except ContentStateInlineStyle and getSampleStateForTesting.

[mitermayer]

Was wondering what is the problem you are trying to solve by having to expose transaction API ? I feel like the least that is exposed the quicker the library to move since it has to maintain less API.

[hellendag]

I figured these would need to be exposed at some point.

My only concern here is that Modifier does a lot of other work to manage changes to entity ranges, and sidestepping those can lead to trouble.

So for anyone using transaction functions directly, it's a caveat emptor situation. :) But that's okay!

[ericbiewener]

I'll throw my support behind this PR. I have a need for getContentStateFragment.

[christophepas]

Is this PR will be merged any time soon ? We would need adjustBlockDepthForContentState to be exposed and I'd prefer use it this way than duplicate the code ;)

[hellendag]

@mitermayer, @flarnie, et al, how do you guys feel about this now? Increasing the exposed API could lead to headaches with API breakage down the road, though I certainly understand the usefulness here -- I assume people are largely hacking around this at this point.

[ericbiewener]

I'm no longer using the function I originally thought I needed access to. I can't remember my use case, but I do recall finding a better way of doing things. Perhaps supporters of this PR should detail their use cases first. Maybe we'll find that there are better approaches for them as well.

[DawnWright]

Is this PR will be merged any time soon ? We would need adjustBlockDepthForContentState to be exposed and I'd prefer use it this way than duplicate the code ;)

We need this exposed as well, so that we can intercept the backspace command and use it to outdent lists (see #187).

[trevtrich]

Any movement on this? We could also use adjustBlockDepthForContentState as some others have noted.

[flarnie]

Looking at this now, my thought is "not yet". I'll discuss with the other Draft maintainers today, but we have other open bugs and API changes underway, and I'd rather reconsider this once other things are cleaned up.

[flarnie]

Sorry to close this, but for now my answer is "not yet" - let's wait to expand the API surface of Draft until we fix some of the remaining bugs and add other features that are in the pipeline currently. I would ask folks to continue using the work-around approach described in the issues linked to this PR, or even copy out the modules you need and maintain a fork if you need custom behavior.