Real world adoption challenges

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 Wrong command given to run the demo app #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!

[tbarbugli]

On a real application you would retrieve the user token from the backend and pass it to the StreamApp component; in fact you would probably not even render the whole StreamApp tree until such token is available.

Thank you for your response! I think I just figured out how to pass the property in my situation to the functional component. It was a bit of a challenge. Everything else worked it was just the issue of getting that value into the StreamApp element.

May not be what you meant, but I don't think in React it is advisable to have the render method wait for an asynchronous process to execute. React is reactive in that the render method needs to execute even if the component is still loading and setting state or props. This is from further reading and understanding about the challenges here.

Different topic but for this in python:
feed_manager.get_feed('feed', 'subfeed')

Originating from stream's context of:
feed_manager.get_feed('timeline', request.user.id)

Is there a way to do that in the react equivalent? I see the sharedFeedManagers on StreamApp which sounds promising but not sure if I'm able to access that in the lower level components with the parent functional component having the StreamApp element. Probably need to move over to SO at this point.

I just tried:

  <FlatFeed
    feedGroup="feed"
    userId="subfeed"
    options={{
      limit: 10,
    }}
  />

And it gave me "you don't have permission to do this", so a 403.

It's a little bit of a reuse of an existing method for my own purpose, but I need that granularity. I'll relinquish this thread if there's not an idea on this and ask on SO. Sorry for trying to workaround what it's really for but I have a reason.

[tbarbugli]

May not be what you meant, but I don't think in React it is advisable to have the render method wait for an asynchronous process to execute. React is reactive in that the render method needs to execute even if the component is still loading and setting state or props. This is from further reading and understanding about the challenges here.

This is totally OK and pretty much done by any SPA that is not rendering static content (ie. loading icon -> render content from API).

    ...
    componentDidMount() {
        fetch(`...`)
            .then(res => res.json())
            .then(result => this.setState({ done: true }))
    }

    render() {
        // use this.state.done
    }

Regarding the second question; keep in mind that the user token used to init the App component must have user_id equal FlatFeed's userId prop.

[tbarbugli]

added a simple pseudo-code example

Okay right, simple IF in the render method. In my example I already had the token in Async storage from my login component so with the await keyword I was having issues. Obviously was missing something. But right if I did the fetch in the mount method as shown that could work.

Gotcha on the userID. In my head I wonder though about the tangent of what value add would it be to allow developers to create sub feeds under the main feed. Makes sense that the original implementation is you ask for the user specific activities from a feed by ID, but think it would also be useful using generated subs like (python):

@property
def activity_notify(self):
    targets = [feed_manager.get_news_feeds(self.user.id)['timeline']]
    if self.city is not None:
        targets.append(feed_manager.get_feed('cityposts', self.generate_sub_feed()))
    if self.user is not None:
        targets.append(feed_manager.get_feed('userposts', self.user.get_token_key()))
    return targets

A wishful ask for a feature be it. Would have to be accommodated for across the stream API's front and back. I see it giving again that flexibility though to just not have elements for one user but really sub categories in the feed. (:

To accomplish what I need I may have to write it routed through my own API and react code. Thanks!