Multiple Actions With Separate Disjoint States

[sinanspd]

I recently picked up Remix in order to build a Shopify Plugin. Essentially the user can pick some combination of settings which gradually refines various data in Shopify as the options are getting picked. Once the data is refined to a "view", the user can do one of many actions such as export, save locally to the app database, send to an external system, create a customer segment etc.

So the action function should be able to one of two things

1. Fetch the data based on the options
2. Perform the final action user chooses based on this data

After doing some research on this, I stumbled upon these two:

https://stackoverflow.com/questions/71123120/remix-usesubmit-arbitrary-data

#3138

I am not entirely opposed to having the logic form inside the action function, but after the second submit, the original actionData is overwritten which causes the already rendered tables and graphs to throw exceptions (as the type of action data is no longer what they expect).

So if I have something like

export const action = async ({ request }: ActionFunctionArgs) => {
    ....
   if(fetch-data-view){
     ... do something ...
  }else{
     ... do something else ....
  }
 }
 const actionData = useActionData<typeof action>();
 const submit = useSubmit();

1. User selects the options
2. submit(fetch-data-view , { replace: true, method: "POST" });
3. Graphs and Tables get rendered based on ActionData
4. User chooses action
5. submit(perform-user-action , { replace: true, method: "POST" });
6. Everything breaks because actionData is no longer the result of fetch-data-view

The hacky solution to this is to unify the result types and have actionData return something like

{
  data-view:  ... 
  resultOfUserAction: ...
}

but I don't like this approach very much.

From my basic understanding, this seems to be in conflict with the architecture remix targets but is there essentially a way for me to have multiple action functions and store the results separately ? So that performing one action wouldn't overwrite the result of the other

If the answer is "you are structuring your code incorrectly", that's fair. I would appreciate any guidance to get in the correct mindset.

[gustavopch]

First, I also think multiple actions should be supported with a more intuitive solution.

But answering your question: fetch-data-view should probably be in the loader. Actions are meant mostly for mutations, not for fetching data. You can also use useFetcher() to be able to keep the data from loaders/actions separated. So if you need to have the actions do-something and do-something-else, you could write them like this:

export const action = ({ request }: DataFunctionArgs) => {
  const formData = await request.formData()
  if (formData.get('intent') === 'do-something') {
    return { outcome: 'did-something' }
  } else if (formData.get('intent') === 'do-something-else') {
    return { outcome: 'did-something-else' }
  } else {
    throw new Error(`Unknown intent: ${intent}`)
  }
}

export default function Component() {
  const doSomethingFetcher = useFetcher() as Extract<ReturnType<typeof action>, { outcome: 'did-something' }>
  const doSomethingElseFetcher = useFetcher() as Extract<ReturnType<typeof action>, { outcome: 'did-something-else' }>
  // ...
}

If you feel there's one action that's the "main action" of that route, then use useActionLoader() for it instead of useFetcher().

[sinanspd]

Thank you for the response. Unfortunately the loader approach is not possible. fetch-data-view is parametrized by what customer chooses. I can not fetch this data on page load because 1) I don't know what the customer will choose 2) If I were to fetch everything and then filter in memory based on customer choices, this query would exhaust Shopify's query cost limit immediately.

There is already a loader in this app. It fetches all the products, extracts some info from the products and renders the options based on those. The customer then chooses some combination of those orders and based on that choice orders, segments and customers are fetched and rendered (this is the fetch-data-view)

I will take a closer look at the Extract type you recommended. Main concern is how it will play out with more complex types and data I don't know in advance. Thank you for the suggestion!

[gustavopch]

You can still use a loader from a resource route. The difference between a loader and an action is really just the method. A loader handles GET requests.

Main concern is how it will play out with more complex types and data I don't know in advance.

You can build a separate resource route for each thing if keeping them together in a single loader/action would be messy.

[sinanspd]

Thank you!