feat: new geoJSON and zip file export api

[ErikSin]

Adds exportGeoJSONFile and exportZipFile

[awana-lockfile-bot]

package-lock.json changes

Click to toggle table visibility

Name	Status	Previous	Current
@comapeo/core		3.1.2	3.2.0
@types/compress-commons		-	7.0.1
@types/crc32-stream		-	4.0.3
@types/readable-stream		-	4.0.18
@types/zip-stream		-	7.0.0
zip-stream-promise		-	1.0.2

[achou11]

Make sure to run the docs generation command after updating the types

[ErikSin]

I suppose this brings up the question of what the overall philosophy is behind this repo. Is it simply just a wrapper for core? Or are we creating custom hooks for the consuming modules?

(personal opinion -so not saying it is the right opinion) I think we should be leaning towards customizing the hooks for the usage of the consuming modules. My mentality is that if it is simply a wrapper, creating an entire repo feels like were just doubling the work. To me the advantage of having an entire repo is we can be more granular with the hooks, with the overall goal of simplifying the code for the consuming modules.

Im curious what your opinion is?

I also think that if the mentality around has been more of just a wrapper, then we probably should keep it that way now for consistency. But perhaps worth having a bigger discussion about this in the future!

[achou11]

(personal opinion -so not saying it is the right opinion) I think we should be leaning towards customizing the hooks for the usage of the consuming modules. My mentality is that if it is simply a wrapper, creating an entire repo feels like were just doubling the work. To me the advantage of having an entire repo is we can be more granular with the hooks, with the overall goal of simplifying the code for the consuming modules.

I'm not against doing this in the future, but because of the various unknowns when it comes to usage of the core api via the hooks, I've opted for keeping the implementation as a more direct wrapper for core. Making it more opinionated adds the risk of "mis-anticipating" the desired end-usage, which is something that isn't ideal for a library from a philosophical perspective.

RE: "doubling the work" - I think this is a potentially valid concern, but I haven't seen much evidence of this being a notable issue so far. if there's anything that has felt like this, I think it's because we're doing unnecessary work to wrap the exposed hooks instead of using functional approaches. I believe what I've written in digidem/comapeo-mobile#1081 is related to this.

I also think that if the mentality around has been more of just a wrapper, then we probably should keep it that way now for consistency. But perhaps worth having a bigger discussion about this in the future!

yeah I'd rather keep things consistent right now and stick with this being a flexible wrapper.

[achou11]

To me, the main benefit of this library is consistent APIs for using core in React and centralized invalidation of data when working with core (which is what React Query specifically provides).

I find it preferable to know that what's exposed here maps directly to what core provides. There's one fewer layer to worry about when it comes to understanding how to use core via React.

[ErikSin]

Make sure to run the docs generation command after updating the types

out of curiosity, is there a reason we dont automate this, specifically as a post push step?

[achou11]

out of curiosity, is there a reason we dont automate this, specifically as a post push step?

mostly just didn't spend the time to figure it out 😄 also, i personally don't like automations that auto-commit code to a branch i work on, so I haven't prioritized looking into it