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]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (09e0d72) to head (663b667).

✅ 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         1824      1830    +6     
  Branches       423       425    +2     
=========================================
+ Hits          1824      1830    +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codecov]

Bundle Report

Changes will increase total bundle size by 1.98kB (0.03%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
@signaldb/core	225.43kB	1.98kB (0.89%) ⬆️
@signaldb/sync	154.42kB	5 bytes (0.0%) ⬆️

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.cjs2.js	284 bytes	31.69kB	0.9%
index2.mjs	284 bytes	31.49kB	0.91%
Collection/index.d.ts	276 bytes	14.64kB	1.92%
index.cjs18.js	281 bytes	10.5kB	2.75%
index18.mjs	265 bytes	10.31kB	2.64%
Collection/Cursor.d.ts	276 bytes	6.42kB	4.5%
.vite/manifest.json	32 bytes	6.07kB	0.53%
ReplicatedCollection.d.ts	57 bytes	3.7kB	1.57%
AutoFetchCollection.d.ts	57 bytes	2.62kB	2.22%
index.d.ts	14 bytes	1.33kB	1.07%
Collection/types.d.ts	152 bytes	1.13kB	15.59% ⚠️

[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]

I think the typings for this feature are still not as good as they should be. The return type of the Cursor methods should be completely generic and inferred by the result of transformAll (like it is for the regular item transform). In general it would be good if the implementation is more similar to the implementation of the existing transform.