Real world adoption challenges

未识别出文件或测试。首先检查示例的函数式 App 组件、StreamApp 的嵌套、token 获取流程以及 react-native-navigation 设置；完成标准应是一个范围明确的更改，或一份说明所支持的身份验证和导航集成的文档。

Before I begin, I was pleased with this example. It's one of the better examples I think that has been done.

First of all I know this example probably was not intended or conceived to be a real world example (it loads dummy data) but please humor me as I struggle to adopt it as such.

1. This example uses a functional component as the App. If I'm wrong please let me know. Thereby from my understanding this means that it cannot have state. To set the stage for why I find adoption challenging, the STREAM_API_TOKEN is a user token generated by the backend and handed to the mobile app per: https://getstream.io/react-native-activity-feed/tutorial/. Naturally this value must either be held already in mobile async storage or better be passed back by an API call asynchronously. Yet we just said this example has a stateless nature. I also referred to: https://getstream.github.io/react-native-activity-feed/#introduction in terms of how the StreamApp component must have the feeds nested. Most of my issues have circled around this as I kept trying to figure out how to pass and construct the components together. Surely we shouldn't pass the STREAM_API_TOKEN by props? Right now my stream client in python is returning the user token by my API.

2. It appears if #1 does work in the real world this example suggests that because the feeds are elements of this "parent" component, the navigation must also derive from the parent component. Currently, I'm using react-native-navigation via method call (not expo or anything else) and so this would require that I probably rewrite how my navigation is built. Any suggestions on what my options are within how the react native activity feed must be designed?

3. I certainly faced the issue in this SO question: https://stackoverflow.com/questions/52110253/you-are-publicly-sharing-your-app-secret-do-not-expose-the-app-secret-in-browse. I sort of understand the answer provided, but also do not because at least in a mobile app (not a server client) I would think you would get the user generated token passed back by API. Am I thinking about the generation of the user token entirely wrong? Should generation be done in a function inside the functional component described in question 1? Could that solve my woes about obtaining the token to some extent? I'm not sure because I still feel I would need some level of stateful / asynchronous interaction for authentication via my API.

Thank you for sharing any advice you may have for easier adoption. Cheers!