What are Single Directory Components?
Let's start here, just in case you aren't sure. The best way to describe this, in my opinion, is to compare it directly to the popular JavaScript front-end frameworks everyone seems to be using these days such as React, Angular, and Vue.js. These frameworks are designed around the concept of components, which are touted as 'building blocks' for user interfaces; Reusable code that accepts arguments and creates the most basic UI element, which can be nested within other components. The "single directory" part of this is really the most operable part of Drupal's implementation of components, and it simply describes how the component is stored in the code base.
Unfortunately, Drupal's SDC plugin lacks the one thing that would make it a true competitor to these JavaScript frameworks: state management.
The State of Things
The way that Single Directory Components work is actually quite nice, and I will be looking at ways I can begin to implement SDCs going forward in my projects now that they are integrated into core and are stable with the release of 10.4/11.0. The idea of keeping UI elements as simple as possible, organizing them into a way that makes sense as far as file structure, and the ability to instantiate them either in a Twig file or in a render array is nice. That said, it's not exactly a ground-breaking idea... rather, it's more or less just a way to move away from hook_theme() and make theme arguments more--what's the word--logical?
Without state management, my belief is that Drupal still has no way of competing with React, Angular, and Vue. That said, what if competition is the wrong mindset? Why reinvent the wheel? Drupal does a really great job of abstraction in areas like database queries, could we do it with UI components and integrate one of these already-made-and-really-good frameworks into the system? After all, "headless" and "decoupled" Drupal has been a growing sub-community for years.
"TBD"
This is what the documentation says about React components:
I have seen a couple of individuals who have found some workarounds to make React work more tightly with Drupal, but it really looks like the better alternative for those who wish to use both is still a very decoupled approach: Drupal is the back-end that sends JSON to a React front-end. This approach requires a lot more thought and, ultimately, time and effort--especially in regard to security.
That said, what this FAQ response tells me is that the SDC team is at least considering (or has considered) integrating React with Single Directory Components. What comes to mind for me is the autocomplete_textfield form element, and the way that is accepts #autocomplete_path as an argument, as well as how we can specify controller or form in a route definition. The ability to write React/Angular/Vue logic within SDCs would certainly be welcome, but as a PHP and Drupal developer, it would be even more welcome if we could specify that the state of a component is attached to controllers I have already written in some way.
The Direction of Drupal Front-End
Of course, what I am proposing is ultimately a change in the direction of how front-end development works within Drupal... at least under the hood. It seems that, by integrating Single Directory Components into core, they have already started taking steps to change the current direction. The question is, how far are we going to go with it? Furthermore, how can we help?
Abstracting an already-abstracted front-end framework feels wrong, but when you think about it PHP is kind of an abstraction of a compiled language itself and the digital world really is built on 9,001 abstraction layers if we're being honest with ourselves. What's one more?