I think @chriskrycho’s round-up of strategies to replace mixins is the best summary one could give. Unfortunately there isn’t one true answer or one single prescription, it depends on what the state is and where it’s going to live.
FWIW you may want to really consider how DRY you want your code to be in the first place. For example in my company’s codebase we have a couple mixins which are used many places but they only contain one property. IMO these don’t really help us much when it comes down to it and can actually make the code harder to unwind. Strict adherence to DRY can push you down some “suboptimal” paths where you’re chasing the wrong abstraction, or trying to abstract too soon just to avoid repeating yourself. I’d recommend this article called “AHA Programming” as food for thought on just how “DRY” you want to be. Not saying that what you want to do is bad by any means just wanted to throw that out there since you are refactoring and probably adapting your mental model to Octane and native classes as we all are.