Feature request: initial data

[malexdev]

I love this library, thanks for sharing!
One thing that I think would be very helpful is if the useAxios hook accepted an option for initial data with which to populate the request.

For example, let's say I have a request that returns an array of objects, from which I am generating a table. I currently need to do something like:

const [req] = useAxios('...')
return (
  <table>
    <tbody>
      { (req.data || []).map((r, i) => <tr key={i}>...</tr>) }
    </tbody>
  </table>
)

It would be nice if I could do something like const [req] = useAxios('...', { initialData: [] }) in the example above so that I don't have to handle the case where req.data is undefined.

If you like this idea, but not enough to bother implementing it yourself, let me know and I'll make time to send a PR.

Thanks!

[simoneb]

hey, thanks! wouldn't the loading flag allow you to do this?

[malexdev]

loading definitely also solves this issue, yes.

I was thinking for interfaces where the loading flag isn't really necessary to use - for example a table of data that almost always populates "instantly" doesn't necessarily need to show a loading indicator, so having an initial data set could make it a little simpler instead of having to conditionally render an empty table based on the loading flag.

But I do agree, the issue is quite minor.

[simoneb]

You don't have to conditionally render, you can simply use the loading flag as the conditional to provide either empty data to the table or the data coming from the response.

[malexdev]

Right, as in (req.loading ? [] : req.data).map(...), which is almost the same as my initial example.
I agree, it's definitely a very minor thing. I'll just keep going as I am then.

Thanks for your time!

[simoneb]

Yes precisely. Don't forget to handle errors too though. You're welcome!

[STotev]

It's best to have initial state of the whole object instead of conditionally creating it.

There are many examples which makes the loading check a little bit inconvenient. If you are waiting for an array response and you do calculations with the expected data, it'll fail until you get a response. It'll be very inconvenient of always checking the loading state before using the data. If you make calculations in multiple places (different phases of the app), declaring an initial empty array, for example, would be helpful because the app will still be running without any extra checks which in this case are redundant.

This is the main reason I uninstalled the package. The package looks good but I'd rather omit those loading checks and write a custom hook myself.
Probably many people will do the same because of the same reason.

Regards,
Stefan

[simoneb]

@STotev What this package is doing is the same as pretty much all other Hooks libraries that allow you to interact with an external service do. Can you share an example of the loading flag making the code so much harder to write?

[STotev]

It's not about "so much harder". It's about cleanliness and redundancy. I am not here to have an argument with anyone. I am not the author, it's your decision what to do. I am just pointing the obvious.

[simoneb]

@STotev can you share your approach so we can see what is the obvious way of doing things?

[STotev]

Let's say you have a calculation(say filtering and sorting results) which you want to memoize using useMemo(). Every time you change the data(updating a record or removing it) you need to trigger useMemo() again so to recalculate the changed data.
Without having data as a dependency on useMemo() I can't use the recalculation. In this case loading doesn't help because it's going to change on REQUEST_START and then REQUEST_END which will trigger useMemo() twice which is unwanted.

P.S. If you expect code, I can make an example tonight.

[simoneb]

P.S. If you expect code, I can make an example tonight.

yes that would be very useful, thanks!