Ms routes app page #295
Ms routes app page #295
Conversation
New actions to get all routes for an app. These were separate methods so that the appGuid could be passed along. The route data that comes from this request doesnt' include the appGuid that the routes belong to, so we pass this guid around so the route store will add it to the data structure. This method of doing this is consistent with the rest of the codebase, and ensures only the stores change data, rather then the API doing it. It also means consistency, as if routes are gotten in a manner where there will be no app guid, then the store has to handle that case.
Pretty simple, what happens on fetch and received.
Uses an normal table as I don't really need the functionality of reactable and I want to get rid of that library anyway. I do the filtering of the routes so I only get the routes thet bleong to the current app in the state setter in the route list component. This is a little different but might be a good solution rather then adding more methods onto the store.
msecret
force-pushed
the
ms-routes_app_page
branch
from
67fff5b
to
dc033c7
Compare
Simple actions for fetching and receiving a domain by domain guid.
The route store's guid has to be matched with an existing route domain_guid. If no route with matching domain_guid exists, it should not do anything. Rather the add new functionality onto base store, this was done by constructing a specific object to use the merge function with. This object is created with a `domain` key that holds the whole domain object and then a domain id which is just the domain's guid. The test seems to show that if the matching route doesn't exist then no new routes are created, which is correct.
| domain | ||
| }); | ||
| } | ||
| }; |
There was a problem hiding this comment.
@msecret what do you think about consolidating these routeActions and domainActions into routeActions?
Here's my thinking: its kind of some CF specific terminology to know the difference between a route and a domain since most of the time you'll actually want both to determine the URL for an application. By having them handled in the same store, but using different action creators and action types it makes it a bit more confusing to hold the difference between a route and a domain in your head.
I think it would make sense to bring all of this into the route*.js files. Thoughts?
There was a problem hiding this comment.
Yea I see what you mean. I think I separated them because there is a just Routes and just Domains view in the community UI, so figured we'd need to separate them conceptually at some point.
There was a problem hiding this comment.
Ya, we can wait for the research team to tell us otherwise, but I have a feeling that the division is hard for most users to understand and that we'll actually be using them in concert.
I'm open either way, which direction do you want to go?
There was a problem hiding this comment.
Ha the one with less work.
Built on top of #290, that should be closed first.
This adds a table below the basic info on the app page for routes. To do this, a RouteStore has been created with all the things that go along with that (actions, constants).
Currently work in progress.