Giters

fastify / fastify-multipart

Multipart support for Fastify

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Create a separate lib for parsing FormData keys with nested objects and arrays

alcidesqueiroz opened this issue · comments

commented

Prerequisites

  • I have written a descriptive issue title
  • I have searched existing issues to ensure the issue has not already been raised

Issue

This PR is about to introduce a new feature that allows parsing FormData keys that use a special notation to represent nested objects and arrays. While this feature is important and relevant to the project, it has enough complexity to perhaps being extracted to its own separate repo, which could be published on NPM as a standalone module. This would be beneficial for several reasons:

  • Reusability: The extracted library would be reusable in other projects, saving time and effort for developers who need this kind of parsing functionality.
  • Simplicity: Separating the parsing logic would make the fastify-multipart codebase simpler and more focused. This would make it easier to maintain and improve, and reduce the risk of bugs or regressions.
  • Community: By releasing this parsing logic as a standalone library, the community would benefit from having access to a well-maintained and tested piece of code that solves a common problem.

Thank you for considering this proposal.

FYI @simoneb

commented

Doesn't a library like that already exists?

commented

@mcollina I believe so, but I couldn't find a battle-tested option that parses Axios-style form data keys (they have a {} special ending that's usually not supported), whose notation I borrowed for implementing our parser.

commented

IMHO in other places we use node:querystering and https://github.com/anonrig/fast-querystring, and they work pretty well.

PTAL https://github.com/fastify/fastify-formbody as well.

Note that we should create this module, I'm just noting that we might not want to make it the default.

commented

We decided with @alcidesqueiroz to create this issue because while working on #437 we realized that behavior, which was the bulk of that change, was quite independent of this library, so we thought it may make sense to build it in a standalone library instead.

commented

+1 on that!

commented

Closing as there doesn't seem to be an appetite to complete this.