Experiment.
No answer presented here will fit your specific product, team or customer. Agile promotes continuous improvement, so go for it.
With that in mind, we can review some key items to consider while experimenting:
Why changing? Have clear the problems the team is intended to address by applying these changes. Changing for the sake of change "to become more agile" is not a real purpose. Your real purpose is to deliver value more often and with predictability. Agile is a tool that can help you on it.
Teams should be able to deliver a complete product. If you organize teams by functional components, you'll have more expertise on this specific component, but you may end up with a great team in UI delivering a lot of changes that cannot be activated because the backend team is not as experienced.
Understand your current knowledge background. If you have a single person doing UI and this is key for all deliveries, having different teams depending on this single person will eventually create a bottleneck.
The knowledge background is one of the most complex changes for fully functional agile teams. If your team relies on specific people's knowledge, before changing the team structure I'd suggest to:
- review the current knowledge background the team members have
- where are the gaps or potential bottlenecks if someone gets sick and then
- discuss with the team who'd like to expand their knowledge background on these areas
Remember, one doesn't need to be expert on all and every area (I still consider a "full stack developer" a fallacy in most cases). Instead, one should have a T-shaped skillset enable every subteam to be able to delivery with minimal dependency of other teams.