I would like to propose to add back the ability to have different collections on different files. The reason this was added can be related to this reported issue https://github.com/firebase/flutterfire/issues/11236.
As summary the sub collection needs to access the _$$ObjectImplFieldMap which is created on the .g.dart file and not explicitly available on other clases.
I believe this is not a good enough excuse as json_serializable has exactly the same problem, models that depend on other models cannot access the private variables or methods, so we are required to expose them not only for our usage, but also so that other constructors can use it.
In this example we can see how modelB depends on modelA, where on modelA we didn't exposed the _$ModelAFromJson method via the factory constructor ModelA.fromJson. However the _$ModelBFromJson is assuming that ModelA.fromJson is defined, which causes a compile error.
My proposal is that we do the same that jsonserializable does, we simply define in the documentation that the $$ObjectImplFieldMap must be exposed, it works for me on the build 62 but I want to keep my packages updated.
if we add to the documentation that we must expose the field map as such, we can bring back sub collections on separate files.
static Map<String, String> get fieldMap => _$$ObjectImplFieldMap
Expected Behavior
I would like to propose to add back the ability to have different collections on different files. The reason this was added can be related to this reported issue https://github.com/firebase/flutterfire/issues/11236.
As summary the sub collection needs to access the
_$$ObjectImplFieldMapwhich is created on the .g.dart file and not explicitly available on other clases.I believe this is not a good enough excuse as json_serializable has exactly the same problem, models that depend on other models cannot access the private variables or methods, so we are required to expose them not only for our usage, but also so that other constructors can use it.
In this example we can see how modelB depends on modelA, where on modelA we didn't exposed the
_$ModelAFromJsonmethod via the factory constructorModelA.fromJson. However the_$ModelBFromJsonis assuming thatModelA.fromJsonis defined, which causes a compile error.My proposal is that we do the same that jsonserializable does, we simply define in the documentation that the $$ObjectImplFieldMap must be exposed, it works for me on the build 62 but I want to keep my packages updated.
if we add to the documentation that we must expose the field map as such, we can bring back sub collections on separate files.
for my current workaround I also need to do a
but I guess we can just update the generator so that it looks for
Object.fieldMapinstead of the_$$_ObjectFieldMapActual Behavior
Steps to Reproduce the Problem
Specifications