feat: collection enrichment

[signalize]

Solution to the "N+1 problem" when dealing with related data. By implementing the enrichCollection option within the Collection definition you can reduce the number of queries required.

changes:

• Introduces the enrichCollection option in the collection
• Created tests
• Created benchmark

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 100.00%. Comparing base (9677cbb) to head (f485217). :white_check_mark: All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1641   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           56        56           
  Lines         1843      1849    +6     
  Branches       433       435    +2     
=========================================
+ Hits          1843      1849    +6     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[codecov[bot]]

Bundle Report

Changes will increase total bundle size by 1.98kB (0.02%) :arrow_up:. This is within the configured threshold :white_check_mark:

Detailed changes

Bundle name	Size	Change
@signaldb/core	220.12kB	1.98kB (0.91%) :arrow_up:
@signaldb/sync	152.72kB	5 bytes (0.0%) :arrow_up:

Affected Assets, Files, and Routes:

view changes for bundle: @signaldb/sync

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
SyncManager.d.ts	5 bytes	8.2kB	0.06%

view changes for bundle: @signaldb/core

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
index.cjs3.js	284 bytes	30.58kB	0.94%
index3.mjs	284 bytes	30.38kB	0.94%
Collection/index.d.ts	276 bytes	14.64kB	1.92%
index.cjs2.js	281 bytes	10.09kB	2.87%
index2.mjs	265 bytes	9.9kB	2.75%
Collection/Cursor.d.ts	276 bytes	6.42kB	4.5%
.vite/manifest.json	32 bytes	6.1kB	0.53%
index.cjs18.js	4.8kB	4.98kB	2745.71% :warning:
index18.mjs	4.8kB	4.96kB	2978.88% :warning:
ReplicatedCollection.d.ts	57 bytes	3.7kB	1.57%
AutoFetchCollection.d.ts	57 bytes	2.62kB	2.22%
index.d.ts	14 bytes	1.39kB	1.02%
index.cjs17.js	-3.7kB	1.28kB	-74.22%
index17.mjs	-3.81kB	1.15kB	-76.76%
Collection/types.d.ts	152 bytes	1.13kB	15.59% :warning:
index.cjs19.js	-1.11kB	175 bytes	-86.37%
index19.mjs	-991 bytes	161 bytes	-86.02%

[obedm503]

Thank you for doing this. Such a good feature!

[maxnowack]

Hi @signalize, that's a really neat idea to solve the N+1 problem! 🙂
I played around with it a bit and noticed some typing issues. Currently, the returned type of an enriched query must match the type of the "unenriched" item, which can be limiting.

Also, this is quite similar to the existing ´transform´ functionality, so I’m a bit unsure about the naming. Maybe something like ´transformAll´ would better capture the intent?

I definitely see the value of this feature, but I'm not entirely sure how it should be implemented. Perhaps we could approach it more generally, like a hooking system, and introduce hooks such as ´beforeFetch´, ´afterFetch´, etc. (since ´enrichCollection´ essentially hooks into query results and modifies them).

This also seems to have some parallels to your other PR, #1618

[signalize]

@maxnowack For now, i changed in to transformAll and improved the return type. Please let me know what you think 😃

[signalize]

@maxnowack FYI, the changes from the pull request #1691 negative effects the 'transformAll' benchmark. When i decrease the amount of inserts to 1000 instead of 10000 it will work...

[maxnowack]

@signalize thanks for the hint! I addressed this issue in #1717 🙂

[maxnowack]

@signalize I saw you made some changes, but then marked the PR as a draft again. So I haven't reviewed it yet. Was this a mistake and you're waiting for my review, or is there still something left to do? 😀