We are a large team aiming to develop a substantial application that will be maintained by multiple developers (approximately 20 teams with 10 developers in each, both onsite and remote).
In Angular (though this might also be relevant to other client-side frameworks), where is the recommended location to maintain the state of a component? Should it be within the component itself or in a service acting as a facade?
First of all, I don't want to sound rude but since you start a huge project I would strongly suggest you to read about the facade pattern again because from your question I can see that you don't completely understand why and how it should be used. The pattern itself has absolutely nothing to do neither with application, nor component state.
Secondly, since you are asking about component state, you answered your own question "where the state should be located?": inside a component. That's the only option. Otherwise it won't be a component state.
I am not going to suggest any of the libs, you can pick whatever you like most.
Additionally, I would like to answer Parsa's comment and his suggestions:
UPDATE 1:
Since an answer to Jon's comments is too long for another comment, I will post it here as an update.
I am not going to argue with Manfred's opinion because (1) he has a lot of experience and even if I disagree, I would still listen to what he says (2) his blog posts and YouTube videos describe just a fraction of his experience and you never know what alternative options he had and what resources at his disposal.
Second video starting from 43:30 explains about facades (personally, I disagree that facades should be used in this case but the video is worth your time).
Additionally, the articles I've read suggest that if a component relies on multiple services, it's advisable to consolidate these services within the facade and expose their functionalities from there. Furthermore, it's recommended that the component itself contains no code and instead relies on the facade for its operations. - exactly what I meant before by saying what resources he had at his disposal. If he used observable data services , then using a facade is an obvious step, otherwise your components will become a mess. BUT if you use, for example, NgRx then your component doesn't interact with any of your services directly. You will use actions and selectors only. This means that services are already hidden behind a "facade" of NgRx.
Of course, you could come to a point when your components start firing multiple consequent actions and subscribing to dozens of selectors. Your first thought would be "I need a facade!" but this is wrong. You are just not using NgRx correctly. This problem is addressed in the first video I recommended.
Considering all of these points, it appears that using facades is the preferred approach. - "... preferred approach for certain scenarios" to be correct.
However, I'm uncertain about what exactly should be placed within the facade ... - any language-agnostic article about this pattern explains it good enough and has enough examples.
... what should go into the service layer, and what should be included within the component. - most of your services will be auto-generated and will be responsible for communication with an API. A facade will simplify calls to those services for a specific use case (i.e., component). A component will call a facade to retrieve or update data.
UPDATE 2:
I found one of the Manfred's sample apps. Here is a typical facade for NgRx store.
As you can see it just proxying calls to store.dispatch and selectors. IMHO, in this case this is an antipattern because you introduce code that doesn't bring any value. One can argue that in this way you can abstract NgRx store and replace it in future with, lets say, Elf. But in reality nobody will ever do it in large apps because this means re-testing the whole app from scratch :)