I completely disagree. There are a lot of organizations that completely abstract the front end from the rest of the stack and have only UI developers work on a very focused piece.
It doesn't help a UI developer to know the DB schema or the middle tier components. They need to know where they can get the data they need and where to send updates. That's about it. It can be helpful if they know business flow (not necessarily logic).
You're involved- or should be involved- in coordinating with back-end developers on the interface from the front-end and the back end. The implementation of that interface depends on the structure of the underlying system; different databases, such as document-based vs relational, can have subtle differences in how your interfaces are implemented and effect the flexibility of said interfaces.
If it's done right, all the details can be (and should be) abstracted away from the FE.
Definition of an API isn't about knowing the 'entire stack'.
A front end dev will need to understand the structure of the API and present needs to whoever is maintaining it but it doesn't matter what the API is coded in since that is most likely abstracted away via the different service interfaces.
Frankly, other than what they are developing the front end in, the only aspect a dedicated front end developer needs access to is the document describing the API so they can make changes there and get their needs to the API owner.
For example, I was working on a multi-step activation system where I had to get the user in a certain state no a specific UI element showed up. That required spending 5-10 min. every time to set up that user, which would go away once you use that button, and development would have taken days.
That is, until someone showed me what the Activation schema + model looked like and how to just toggle the boolean or attach an expected relation. You could maybe argue that there should be an admin interface for manipulating model state, but nobody else really would need it: BE devs can already change the models, and business types don't care about this particular state of the user.