fkhadra / fkhadra/react-toastify
Have the "type" property accept a function that receives data when using toast.promise
- 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
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