Closed charitha93 closed 1 year ago
While this can be a convenience in your case to get automatic file downloading, when we consider core of what this library accomplishes, it is primarily about converting geoJSON to shp data. The download function is really a secondary functionality, and is quite outdated. If you look at the API surface for zip
and download
, there is a lot of overlap because we end up duplicating a lot of flags to call zip
when we call download
.
If we think about this another way, there are people who want to use this library without downloading the files. If you just want the raw zip data, you want to just call zip(...)
. So if you want to download the zip data, then it would be nice if we could call it like this: download(zip(...))
. This would be a much more composable and flexible pattern.
Then if we want to download non shp data, or anything else, we can re-use the download(...)
function there. Therefore, it doesn't make sense for this library to maintain the download functionality when other libraries do this functionality much better. If I try to consider the use cases of people who use this library
Only the fourth use case is served by this libraries internal download function, and the other three are required to either work around or ignore the functionality.
I don't have plans to remove the download anytime soon, but I end up maintaing this library for the long term, it would help my workflow to not have to deal with superfluous functionality.
Hope that makes sense!
I understand that that download function has been marked for deprecation. I just wanted to understand the reason behind it. There are plenty of use cases for it and myself and a few other devs are currently using as it makes things a lot easier for browser downloads without any additional hassle