Architecture to Support More Return Methods (React/Vue/etc)

[shshaw]

Along the discussion for #20 and longer term planning for 2.0:

• DOM-independent API methods ( splitText, childNodes, etc. )
• Splitting.jsx return method that takes a framework's createElement function and returns the proper calls for that to implement splits
• Splitting.array to return just an array of split based on content/target without touching the DOM or creating elements. This could be useful for custom split creation in a framework and certain JavaScript animation libraries.
  • words could return ['hello', 'world']
  • chars could return ['h', 'e', 'l', 'l', 'o', ...]
  • items could return [ ChildNode, ChildNode ]
  • dom: true Perhaps an option to do the element creation/DOM adjustments? Wouldn't be much different than Splitting(), but the return would be a little more direct and ready to use for a JS lib.
• <Splitting/> component for React & Vue?

[shshaw]

Relevant discussions:

shshaw [11:46 AM] So thinking through the feedback. Splitting’s very good in its current state, but I am wondering about making the pieces a bit more abstract to allow for JSX style support, returning only an array, etc. Splitting() should always be DOM focused, but then additional methods, like Splitting.html() open up different return types

notoriousb1t [11:48 AM] the internals would have to work completely differently for that to work and some plugins would simply not work; namely lines and grid I think there is real value in reworking the internals, but I would caution against changing the signatures in a large way

shshaw [11:50 AM] Sure; I don’t want to completely overhaul or bulk up the size. The main modifications would be to splitText and createElement, I believe.

notoriousb1t [11:52 AM] the real challenge there is that all dom interactions need wrappers that need to provided through a context object so, getting a list of children for instance

shshaw [11:54 AM] Yes. Hm. Just food for thought, not anything to specifically move on for 1.1 or anything, but perhaps 2.0 territory

notoriousb1t [11:54 AM] I think we should definitely keep the discussion going there is a lot of value in getting it working with various frameworks, the question is... how can we do that without wrappers or explicit framework hacks

shshaw [11:56 AM] I’m not fully opposed to a splitting-react or splitting-vue to offer a <Splitting> component, but I think we still need to have the architecture adjusted to support that

shshaw [12:04 PM] Perhaps all of this could be done in a splitting-frameworks library without ballooning the core library. Reuse the methods that make sense, add new ones for the specialized features. Splitting.jsx, <Splitting/> etc.