Implement a basic addons page

[Ivshti]

Describe the solution you'd like
Like the Discover page but uses CatalogFiltered<Descriptor> rather than CatalogFiltered<MetaPreview>

Copy the design from stremio-web

Later on we'll add an "Installed" category and Search

Additional context
because the Load action gets sent to both, we need an additional enum to distinguish between a Load that has to be dispatched to the discover or to the addons

[MartinKavik]

@Ivshti Can I start working on it?

[Ivshti]

Yep!

[MartinKavik]

Demo: https://stremio-seed-poc.netlify.com/#/addons

• Note: Modal dialog content is hard-coded for now - only show/close has been implemented.

Later on we'll add an "Installed" category and Search

• I realized too late that "installed" is probably "my" - so it's already implemented.
• Simple search is also implemented as the one short function.

because the Load action gets sent to both, we need an additional enum to distinguish between a Load that has to be dispatched to the discover or to the addons

• Do you want to modify core? (i.e. add that enum into it)
• Should it resolve some (edge) cases or what's the reason for this?
• I don't know reasons, but one alternative would be something like correlation_id or request_id so we would distinguish requests/responses in apps and, for instance, we would be able to abort the request on a flight when we don't need response anymore.

[Ivshti]

Looks amazing so far!

Btw, you should clear the search when switching catalog.

Search can be continued with:

• Search model stremio-core#94
• in-memory search for various models stremio-core#93
• research search libraries for implementing searchIndex spec stremio-core#38
• but we should spend some time discussing this

re the questions:

• modal should be implemented as per PromptStack model stremio-core#80 ; for now, what you did is OK
• yeah
• cool
• No. Dispatching this Load to the right place should happen in the application level as it is now. app.discover.dispatch vs app.addons.dispatch instead of app.dispatch; You probably already have such an app-level enum of actions, so you just stick it there.
• It's because both addons and discover content is loaded using the addon system, and the Load is completely the same; So what would happen is, when you emit a Load with an addon catalog to the entire app, both the addons/discover CatalogFiltered instances would handle it, and would do a network request; this is not only redundant, but would cause a CatalogError::UnexpectedResp in the discover instance; anyway, if you dispatch it to the right model, this problem doesn't exist
• we considered this and decided against using an id, simply because the edge case is pretty rare; in many cases we do want to dispatch an action to all models that can handle it

Side note: we're getting closer to a very solid PoC status, please continue with the detail page.

All of the large tasks that still need to be done on the addons page should be documented as issues (if there aren't such already)

[MartinKavik]

Closing for now, implementation is enough for the PoC scope.