pr1sm
commented
6 years ago I think option 1 seems better in the long run too. If we go with option 1, there is an implied feature we have to tackle -- how to "remotely" trigger actions within redux. This is because the source of supported sites will have to "remotely" trigger an action to update the site list in the following cases
- Filling in the initial supported sites
- Adding a supported site after the action is created (we add support for a site)
- Removing a supported site after the action is created (we drop support for a site)
A couple of ways to deal with this are opening websockets, or polling for information. After doing some research, I think that websockets are a more stable, responsive way of receiving data from requests, but I think polling for information is easier to start with.
Because of this, we should think of an independent way of making a connection, then receiving events from the connection to trigger redux actions. This way, the redux side of things doesn't need to know if it's using websockets or polling; it simply knows how to [re]start/stop a connection and handle messages received from the connection, transforming them into redux actions. We can then start with a polling solution, then create a websocket solutin and drop it in without having to modify the redux side of things at all.
walmat
I've been thinking through more of the process pipeline for tasks and I've come to the conclusion one of two things need to happen in order for me to proceed with the pipeline.
Option 1.
We need to restructure the creating tasks a bit to accommodate the "supported site" gathering. This would mean that when a user clicks submit after filling out their task information, we would gather the supported sites for that SKU (either by some custom search algorithm, or some sort of functionality we have within the discord-bot integration) and display a simple number of supported sites in the view tasks table for the user to see. This would of course need to be stored as an object in the task's individual state AFTER the user submits a task.. so this would be done in an API call or something similar.. Anyway here's what I was thinking, more could be added later that I'm not thinking of right now:
This wraps up option 1, and honestly gets my vote if you ask me.
Option 2.
We keep the current design, but only serve the information to the user when they start the tasks. This would build the task log similarly as before, but the only downside here is the user doesn't know what is supported (if anything) before they ever start the task. The logical flow would work the same as option 1 though, just called at a later point in time.