Merge flutter and dart package

[mbfakourii]

New Feature / Enhancement Checklist

• [x] I am not disclosing a vulnerability.
• [x] I am not just asking a question.
• [x] I have searched through existing issues.

Current Limitation

I have a question, why do we have two packages? Is it possible to integrate Flutter package with Dart? I checked that there are only 6 files in the Flutter version and most of them are utilities! With this, we will no longer get involved in the conflicts of two packages.

Feature / Enhancement Description

I suggest to merge two packages into one package

Tasks

• [ ] Add migration guide to new package

Roadmap

• 1. Merge https://github.com/parse-community/Parse-SDK-Flutter/pull/855

[parse-github-assistant[bot]]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mbfakourii]

The only basic part that exists is ParseLiveList, which can be implemented in Flutter in different ways.

I think it is possible to prepare an example for this issue instead of having a separate package!

[mtrezza]

Maybe @phillwiggins who is the original author of this SDK (and who we all owe a cup of coffee I believe ;-) can say something to it. I believed it started with the dart package and flutter was developed later on, on top of it. I believe the dart was kept separate for developers who are depending on it and don't need the additional flutter capabilities.

[Nidal-Bakir]

I do not have any answers to this question.

But at this point, it is nearly impossible to merge them together with thousands of developers using each one.

[mtrezza]

I don't see an issue with merging them and releasing as a new version if the benefits outweigh the costs, maybe with a transitory phase for developers to migrate. But I think we'd need to analyze the implications of providing only 1 package first to make a decision.

[Nidal-Bakir]

One package is for Dart and another one is built on top of the Dart package, for Flutter.

The reason for this is that Flutter has its own set of unique widgets and libraries that are not available in Dart. When developers create packages that are specifically designed for Flutter, they need to use these Flutter widgets and libraries to make their package work properly within the Flutter framework.

So, the Dart package contains the core logic and functionality of the library, while the Flutter package contains the code that is necessary to integrate that functionality with Flutter-specific widgets and libraries. This separation of concerns makes it easier for developers to use the package in their Flutter projects, without having to worry about the underlying Dart code.

For example, let's say we need to implement a portable UI like login/sign-in like firebase UI where we will deal with login/sign-in using email and password, using a google account, or using a Twitter account. well, we can do just that in the flutter package. rather than create a separate package to do that.

The point of the dart package is to keep it isolated from anything else. It is just pure product/domain logic.

[mbfakourii]

One package is for Dart and another one is built on top of the Dart package, for Flutter.

The reason for this is that Flutter has its own set of unique widgets and libraries that are not available in Dart. When developers create packages that are specifically designed for Flutter, they need to use these Flutter widgets and libraries to make their package work properly within the Flutter framework.

So, the Dart package contains the core logic and functionality of the library, while the Flutter package contains the code that is necessary to integrate that functionality with Flutter-specific widgets and libraries. This separation of concerns makes it easier for developers to use the package in their Flutter projects, without having to worry about the underlying Dart code.

For example, let's say we need to implement a portable UI like login/sign-in like firebase UI where we will deal with login/sign-in using email and password, using a google account, or using a Twitter account. well, we can do just that in the flutter package. rather than create a separate package to do that.

The point of the dart package is to keep it isolated from anything else. It is just pure product/domain logic.

In my opinion, why is there a need to design a graphic page in Parse package? In my opinion, this can be implemented separately in Flutter, it does not need another package

These parts that are currently in Parse's Flutter package can all be implemented and inherited in Flutter. So what is the need for the Flutter version?

There is no problem about the merge to one package, we can give a final version for Flutter and say that it is deprecated and...

[mtrezza]

I’ve pinned the issue to give it more visibility in case someone wants to chime in.

[pastordee]

One package is for Dart and another one is built on top of the Dart package, for Flutter.

The reason for this is that Flutter has its own set of unique widgets and libraries that are not available in Dart. When developers create packages that are specifically designed for Flutter, they need to use these Flutter widgets and libraries to make their package work properly within the Flutter framework.

So, the Dart package contains the core logic and functionality of the library, while the Flutter package contains the code that is necessary to integrate that functionality with Flutter-specific widgets and libraries. This separation of concerns makes it easier for developers to use the package in their Flutter projects, without having to worry about the underlying Dart code.

For example, let's say we need to implement a portable UI like login/sign-in like firebase UI where we will deal with login/sign-in using email and password, using a google account, or using a Twitter account. well, we can do just that in the flutter package. rather than create a separate package to do that.

The point of the dart package is to keep it isolated from anything else. It is just pure product/domain logic.

This is exactly why the flutter package was created I’ve been using this from day one and it was all together, but then they decided to separated so the dart package which is the core can be on his own and flutter and any other package can be built on top of it so I think we should leave it separated.

[mbfakourii]

Benefits

1: Focus on one package 2: Not getting involved in conflicts 3: The absence of two separate documents (both of which are almost the same!) 4: Almost most famous packages use one package (having harmony with other packages) 5: Fix pub dev problem in Provide documentation and Package has an example section (Because of the two packages, the pub.dev site cannot find the example!) 6: Less use by programmers of the Flutter package than the Dart version 7: It has almost no use when programming (in my experiences in a big project, I used the Dart package and there was no need for the Flutter package) 8: The possibility of collecting the tests of the whole project in one section 9: Easy to deploy project on pub dev 10: Clarity of the issues that are created (it is not clear for which version an issue is presented and also in PRs) 11: After the merge, there is no problem in terms of version, because if users like it, they can still use the deprecated version of Flutter which is on the pub dev site.

Costs

1: Review and update CI based on new changes 2: Problems that may occur on different platforms (I don't give much probability) 3: The difficulty of transferring development from Flutter version to Dart

[pastordee]

I used to use the IOS and the Android package of the SDK and the UI version was called ParseUI which had tableview, login UI and other UI element, It was all together in one package, so I suppose we could do the same and put the flutter package under a UI folder.

https://github.com/parse-community/ParseUI-iOS

[mtrezza]

Just a note here, we are generally moving from separate packages (repositories) to single ones were feasible. The maintenance effort is just considerably higher for more GitHub repositories. It's mainly historic reasons why many of our SDKs span across multiple repositories/packages.

For example, the LiveQuery feature is now being integrated into the main iOS SDK. Some package managers offer to optionally add submodules of a package, so it's 1 package in the registry, but a developer can choose to install only a subset of modules. I suppose that's not an option here?

[Nidal-Bakir]

Should we drop the support of the Dart SDK or the Flutter SDK?

Dropping the Dart SDK

• Migrate the Dart SDK to be included in the Flutter SDK.

• Deprecate the Dart SDK in favor of including it in the Flutter

  Pros:

  • we can include any UI-related widget in the SDK directly
  • we will manage and develop one repo/package for the SDK

    Cons:

  • we are now coupled with the Flutter framework.
  • the SDK can not work in any context outside the flutter framework

  Dropping the Flutter SDK

• We can not migrate the Flutter SDK to be included in the Dart SDK.
• What should we do with any UI-related component?
  • should we keep the Flutter SDK?
  • should we rename the package to "Prase Flutter UI"?
  • what should we do with it? should we remove it?

Pros:

• we are now independent of the Flutter framework.
• the SDK can work in any context outside the flutter framework
• we will manage and develop one repo/package for the SDK

  Cons:

  • we can not include any UI-related widget in the SDK directly
  • if we need any UI-related component, we must create a separate package.

[Nidal-Bakir]

There is a significant trade-off when doing such a thing, the question we need to ask ourselves is whether the benefits of doing it are worth the costs.

[mtrezza]

Due to this issue here we currently have 2 PRs on hold:

• https://github.com/parse-community/Parse-SDK-Flutter/pull/846
• https://github.com/parse-community/Parse-SDK-Flutter/pull/844

If we cannot make a decision in the near future about merging the 2 packages, then I'd suggest to merge the 2 PRs above and publish a single breaking major release of the flutter package. So we can take our time in coming to a decision about the package merging.

[mbfakourii]

Due to this issue here we currently have 2 PRs on hold:

• feat: Rename the source file for Flutter package #846
• feat: Upgrade various dependencies and fix warnings in flutter package #844

If we cannot make a decision in the near future about merging the 2 packages, then I'd suggest to merge the 2 PRs above and publish a single breaking major release of the flutter package. So we can take our time in coming to a decision about the package merging.

In my opinion, it is better to merge because it has more benefits.@mtrezza The decision is yours, do you agree?

[Nidal-Bakir]

I am leaning toward the idea of having one SDK which is the Dart SDK.

i.e. drop the support of the Flutter SDK or move it to a separate repo under a different name like Parse_Flutter_UI

[mbfakourii]

I am leaning toward the idea of having one SDK which is the Dart SDK.

i.e. drop the support of the Flutter SDK or move it to a separate repo under a different name like Parse_Flutter_UI

It is a good suggestion, but in my opinion, Parse_Flutter_UI is not very useful, but this method can be implemented

[mbfakourii]

@Nidal-Bakir In your opinion, what widgets can be designed in Parse_Flutter_UI?

[Nidal-Bakir]

let me clarify.

move it to a separate repo under a different name like Parse_Flutter_UI

I mean to rename the Flutter SDK (parse_server_sdk_flutter) to Parse_Flutter_UI and create another repo for it.

since it holds only a UI component, not the actual SDK

[mtrezza]

We want to avoid creating another repository unless there is a strong reason. As I mentioned previously, we are moving towards consolidating repositories in other SDKs. It can of course be a separate package, a similar structure as it is now.

[Nidal-Bakir]

Then we need to drop the support of the parse_server_sdk_flutter

[Nidal-Bakir]

Or go with the other option dropping the support of the parse_server_sdk and include it in the parse_server_sdk_flutter

[mtrezza]

The SDK shouldn't know the difference whether it has a repository on its own, or whether it's a package in a mono-repository. Are there any implications from that?

[mbfakourii]

let me clarify.

move it to a separate repo under a different name like Parse_Flutter_UI

I mean to rename the Flutter SDK (parse_server_sdk_flutter) to Parse_Flutter_UI and create another repo for it.

since it holds only a UI component, not the actual SDK

@Nidal-Bakir I have a suggestion for ui widgets to create an example and put ui widgets in it. Anyone who needed to use those classes, what do you think? For example, example_ui

[Nidal-Bakir]

@mbfakourii that is a great idea

[Nidal-Bakir]

@mtrezza I do not think I understand the question. can you explain more about what are you referring to?

if understand correctly, I do not think its matters or has any implications if the SDK is in mono-repo or in a stand-alone repo

[mbfakourii]

@mtrezza So we decided to have only one package for Dart and a folder called example_ui where the graphical widgets are placed. Do you agree?

[Nidal-Bakir]

sure, but until now we did not decide what package should we choose to migrate all the code to it. so we can discase about it further

Should we drop the support of the Dart SDK or the Flutter SDK?

Dropping the Dart SDK

* Migrate the Dart SDK to be included in the Flutter SDK.

* Deprecate the Dart SDK in favor of including it in the Flutter

Pros:

* we can include any UI-related widget in the SDK directly

* we will manage and develop one repo/package for the SDK

Cons:

* we are now coupled with the Flutter framework.

* the SDK can not work in any context outside the flutter framework

Dropping the Flutter SDK

* We can **not** migrate the Flutter SDK to be included in the Dart SDK.

* What should we do with any UI-related component?

  * should we keep the Flutter SDK?
  * should we rename the package to "Prase Flutter UI"?
  * what should we do with it? should we remove it?

Pros:

* we are now independent of the Flutter framework.

* the SDK can work in any context outside the flutter framework

* we will manage and develop one repo/package for the SDK

Cons:

* we can **not** include any UI-related widget in the SDK directly

* if we need any UI-related component, we must create a separate package.

[mbfakourii]

sure, but until now we did not decide what package should we choose to migrate all the code to it. so we can discase about it further

Should we drop the support of the Dart SDK or the Flutter SDK?

Dropping the Dart SDK

* Migrate the Dart SDK to be included in the Flutter SDK.

* Deprecate the Dart SDK in favor of including it in the Flutter

Pros:

* we can include any UI-related widget in the SDK directly

* we will manage and develop one repo/package for the SDK

Cons:

* we are now coupled with the Flutter framework.

* the SDK can not work in any context outside the flutter framework

Dropping the Flutter SDK

* We can **not** migrate the Flutter SDK to be included in the Dart SDK.

* What should we do with any UI-related component?

  * should we keep the Flutter SDK?
  * should we rename the package to "Prase Flutter UI"?
  * what should we do with it? should we remove it?

Pros:

* we are now independent of the Flutter framework.

* the SDK can work in any context outside the flutter framework

* we will manage and develop one repo/package for the SDK

Cons:

* we can **not** include any UI-related widget in the SDK directly

* if we need any UI-related component, we must create a separate package.

Dropping the Flutter SDK

[mtrezza]

if understand correctly, I do not think its matters or has any implications if the SDK is in mono-repo or in a stand-alone repo

That was my question, alright then.

We decided to have only one package for Dart and a folder called example_ui where the graphical widgets are placed.

Sounds good.

[mbfakourii]

if understand correctly, I do not think its matters or has any implications if the SDK is in mono-repo or in a stand-alone repo

That was my question, alright then.

We decided to have only one package for Dart and a folder called example_ui where the graphical widgets are placed.

Sounds good.

So I open a PR for merge

[mtrezza]

If you are sure about this go ahead. If you think it could be beneficial to tweet out to the community just in case someone wants to join the conversation or you're looking for more opinions, let me know.

[catalunha]

Dear @Nidal-Bakir and @mtrezza , I'm starting a project in Flutter with the following structure:

lib/
pubspec.yaml [ parse_server_sdk_flutter: ^3.1.3]
packages:
..package1:
..,..lib/
..,..pubspec.yaml [ parse_server_sdk: ^4.0.0]
..package2:
..,..lib/
..,..pubspec.yaml [ parse_server_sdk: ^4.0.0]

And the following error was obtained:

Resolving dependencies...
Because parse_server_sdk_flutter >=3.1.3 depends on parse_server_sdk ^3.1.2 and every version of user_repository from path depends on parse_server_sdk ^4.0.0, parse_server_sdk_flutter >=3.1.3 is incompatible with user_repository from path.
So, because sumat_bloc depends on both user_repository from path and parse_server_sdk_flutter ^3.1.3, version solving failed.
pub get failed

Due to the dependency that parse_server_sdk_flutter has on parse_server_sdk this error should not happen. Do you agree? If this is not an issue, or relevant, I apologize and I will research how to work around this situation in my project.

[Nidal-Bakir]

@catalunha This is an expected issue. because the parse_server_sdk_flutter is not updated to use the latest parse_server_sdk.

Once these 2 PRs merged. the issues will be fixed automatically

844 #846

We are doing our best to fix everything.

[catalunha]

Thanks. I congratulate and thank you and the others for your serious and caring work. I wish I had you enough knowledge to help in this context. I'm struggling with my studies here. We will wait.

[Nidal-Bakir]

As a workaround for now you can use parse_server_sdk: ^3.1.15 rather than parse_server_sdk: ^4.0.0

I can not merge any PR because @mtrezza is the only one who can do that. if he is not available we can not do anything

[catalunha]

Yes. It was my solution. Grateful.

[mtrezza]

@Nidal-Bakir The 2 PRs you mention are not merged because we wanted to merge the packages first to reduce the number of breaking change releases. Now that it turns out to be a longer discussion, please comment on each of the PRs you would like to merge. As I mentioned in the other thread, if there are any PRs that should get merged, then let's merge them and not wait for the other discussion.

[Nidal-Bakir]

@catalunha The issue has been solved now, we just released parse_server_sdk_flutter: 4.0.0

[mtrezza]

Closed due to https://github.com/parse-community/Parse-SDK-Flutter/pull/852#issuecomment-1476409312