fkhadra / fkhadra/react-toastify

Have the "type" property accept a function that receives data when using toast.promise

Open
#819 1 comment 0 reactions 0 assignees View on GitHub
Feature Request
Dominant language
TypeScript
Stars
13.4k
Forks
741
PR merge metrics
No merged PRs in 30d

Description

**Do you want to request a *feature* or report a *bug*?**

I want to request a feature

**What is the current behavior?**

Currently, when using toast.promise you can only set a toast's type as a string, eg.:

```
toast.promise( fetcher, {
success: {
render: ( { data } ) => "Post ${data.title} was successfully created!",
type: "success"
},
error: {
render: "Something went wrong!",
type: "error"
},
})
```

**What is the expected behavior?**

It would be nice if `type` accepted a function that receives the data (just like `render`), and determine the type based on that data. I'm asking because eg. when requesting data with GraphQL, the request may be successful (ie. the fetcher doesn't throw an error, so the error toast is not used), but the successful response may still contain errors, so I would basically turn the success toast into an error toast, something like this:

```
toast.promise( fetcher, {
success: {
render: ( { data: result } ) => {
const { data, errors } = result
return errors ? "Something went wrong" : "Post ${data.title} was successfully created!",
},
type: ( { data: result } ) => {
const { data, errors } = result
return errors ? "error" : "success"
},
},
error: {
render: "Something went wrong!",
type: "error"
},
})
```

I am currently working around this by using a try/catch block and toast.update as explained in #726, but I like the toast.promise signature better :)

Contributor guide

Open the contributing guide

Research direction

Start at the toast.promise API and trace how the success render callback receives its data and how the type string is applied. Compare the proposed behavior with the toast.update workaround described in #726; done means a success configuration can derive its toast type from the resolved data while existing string types continue to work.

Written by the indexing model from the issue text.

Assessment

Tech stack
react, typescript
Domain
frontend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.