Implementing 8-direction animation in Unity using Spine can be approached in several ways, and the best method often depends on your specific requirements and constraints. Using a SkeletonAnimation component and dividing the state into 8 directions is a valid approach, especially if you want to have precise control over each direction. However, it can become cumbersome if you plan to expand to 16 directions.

An alternative approach is to use a single state for actions like idle or move and then determine the direction in your code. You can dynamically set the animation based on the character's direction by manipulating the SkeletonAnimation component. This method can be more efficient and scalable, especially when dealing with a larger number of directions. You can also consider using a blend tree in Unity's Animator to handle direction changes smoothly.

For more complex setups, you might consider using a single skeleton that can face multiple directions by flipping or rotating parts of the skeleton, as suggested in some of the forum discussions. This can reduce the number of states you need to manage and make your animations more flexible.

thcha Is this the right way to implement it?
Or is it the right way to set only states such as idle and move and get the state from the code and set the direction?

As Spinebot mentioned, there is no single right way. In general having a Mecanim subtree with single states for 8-direction movement is a valid approach. I don't see why it would not scale well with 16-direction movement (creating all the animations would likely be the larger effort).

Note however that the hybrid approach shown in "Mecanim Logic SkeletonAnimation view" of controlling animation via Mecanim while in the end targeting a SkeletonAnimation component is not the primary recommended approach. This always comes with some limitations, as it's mapping one limited system onto another. In general we always recommend directly using the SkeletonAnimation component and SkeletonAnimation.AnimationState if you can, and issuing the respective AnimationState.SetAnimation() calls via code. Your movement components can use AnimationReferenceAsset object references if you prefer drag-and-drop assignment of animations, or have [SpineAnimation][SerializeField] string animationUp; if you prefer selecting animations from a list.