This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit c7bf3bf:

This is a very cool idea and well documented! Excellent bar of quality as usual @Zyie.

Would you mind creating a quick demo (maybe with animation) to showcase this?

I have one general concern which is about destroying lifecycle. Since the split result is a generic object, I don't see an easy way to destroy the extra text elements and containers. Our contract generally is: if Pixi instantiates it, Pixi destroys it. How would a user do that here? Also replace removes it from the display tree, but does not destroy, right?

Another API approach might be to introduce a new display class to manage the element more directly (maybe that extends Container). Something like TextAnimator, TextSegmenter. This gives us more flexibility in the future and maintain the current contract with objects created and objects destroyed.

const myText = new Text({
  text: 'Hello World',
  style: {},
});

const seg = new TextSegmenter({
  element: myText,
  replace: true,
});

seg.chars.forEach((char, i) => {
  char.alpha = 0;
  // Fade in each character sequentially
  gsap.to(char, {
    alpha: 1,
    delay: i * 0.1
  });
});

seg.destroy();

Would you mind creating a quick demo (maybe with animation) to showcase this?

Here is a demo link:
https://codesandbox.io/p/sandbox/pixi-js-sandbox-forked-chgp88
https://codesandbox.io/p/devbox/pixi-js-sandbox-forked-yly7k3

I have one general concern which is about destroying lifecycle. Since the split result is a generic object, I don't see an easy way to destroy the extra text elements and containers. Our contract generally is: if Pixi instantiates it, Pixi destroys it. How would a user do that here?

So the result from Text.split returns an object like this:

interface Result {
  container: Container;
  lines: Container[];
  words: Container[];
  chars: Text[];
}

So to destroy the new text you would use result.container.destroy(true).

Also replace removes it from the display tree, but does not destroy, right?

That is correct. It doesn't destroy the original text. My thinking was that you might want to split the text up for an animation, then swap it back for the original.

Another API approach might be to introduce a new display class to manage the element more directly (maybe that extends Container). Something like TextAnimator, TextSegmenter. This gives us more flexibility in the future and maintain the current contract with objects created and objects destroyed.

const seg = new TextSegmenter({
  element: myText,
  replace: true,
});
seg.destroy();

I'm not against this approach either. It aligns with what i had in mind originally before going down the current path.
@GoodBoyDigital any thoughts?

Also just as a note that this is all inspired by the gsap plugin that does this for html text: https://gsap.com/docs/v3/Plugins/SplitText/

Me and Mat had a quick chat about this today and agree that we should go down the TextSegmenter route. I'll update the PR accordingly!

Cool. The benefit of an explicit class destroy is that it will also handle all the dereferencing for lines, words, chars arrays.

@bigtimebuddy ready for another review