You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 firebase/flutterfire#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 json_serializable 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.
staticMap<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 firebase/flutterfire#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 constructorModelA.fromJson
. However the_$ModelBFromJson
is assuming thatModelA.fromJson
is defined, which causes a compile error.My proposal is that we do the same that json_serializable 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.fieldMap
instead of the_$$_ObjectFieldMap
Actual Behavior
Steps to Reproduce the Problem
Specifications
The text was updated successfully, but these errors were encountered: