-
There are 8 different What is the tree-shaking story for these? In my code, I do:
i.e. I end up using the same The current watershed is at whether I follow any of the data, at all. If I do, I get the code for following document, collection, and query, all in the same function. Another option would be to shed the water between reference or query. This way, Personally, I see that if someone uses Firestore, they likely want to follow the data in near real time instead of doing the imperative get's that of course are also possible. This could imply always, implicitly, bringing I don't care about one API over the other, but I do care about the tree shaking efficiency. As to that, my first experience is:
That is a slight disappointment since I only use app, auth and firestore. I was expecting something like 400kB instead. These numbers are not the final word, but made me think about tree shakability not as a given, but a careful balance. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 8 replies
-
More details on the build density (trying not to divert from the topic; EDIT: Due to a packaging glitch,
Overall compressed size of 88,23kB is very welcome. :) EDIT: After cleaning up my packaging, the end result is an app with:
|
Beta Was this translation helpful? Give feedback.
More details on the build density (trying not to divert from the topic;
this only shows that Firestore is not the problem with 0.900.15; auth still is):EDIT: Due to a packaging glitch,
auth
ended up packaged twice in the numbers. Striking out expired notions.