Load playground's exported json in an app

[MaxLap]

Have you thought about moving the playground's JSON import/export system into the core package? I think it would be a nice addition.

The idea would be that instead of copying "Theme code", apps could instead load that JSON configuration and create the Theme code either at runtime or create a genenrated file with a command (or during build? I don't know if that's possible).

Benefits:

• No need to copy both the "Theme code" and the JSON as an "In case I want to edit in playground again later"
• Reduce the chances that the used theme is different from what is seen in the playground. (Either someone forgot to copy the JSON, or manually edited the theme's code).
• Reduce the changes of the playground's code overwriting a manual change to the theme's code.

I'm aware that the playground can't do everything that this package is capable of. If a dev needs those (more advanced?) feature, it could be done as manual changes after loading the configuration (or as a second argument to the generating function). This way, for those devs, the manuals tweaks are easy to see/find, and updating the config doesn't default to overwriting their tweaks.

If that was to be done, I would then suggest too make the import/export more easily accessible and visible. Maybe put it as part of the "Theme code" section (I mean it's already there, but at the end, easy to miss).

PS: This project is very impressive and your maintenance work here even more so. Few open issues/PR and your replies to them and your answers to them and to discussions are very thorough.

[rydmike]

Hi @MaxLaps,

First off, many thanks for sponsoring the project! 🙏🏻 Much appreciated 😃

To the questions...

It is not impossible, nor a bad idea. I have been thinking about it myself as well, even though I have originally stated (see https://docs.flexcolorscheme.com/future_features#out-of-scope) that the package is not intended to support serialization of its configuration and persisting it. But having seen the success and popularity of that in the companion app Themes Playground I'm beginning to change my mind.

The solution used in the Themes Playground can however not be transferred to the package directly. That solution is kind of a hack by serialization of the UI control states in the Playground app only. The FlexColorScheme package itself has no knowledge about the serialized format and currently does not support serialization of its data.

The URL sharing of the Playground config is then just encoding and compressing the entire Playground json as a super big query param. The config can then also be shared with anybody as a URL link without any server storage of the config. Current version of the Playground is totally serverless (other than hosting the static single page app), it also does not log anything about users and usage.

However, this does not mean it could not be done. The Playground's own solution could even co-exist with it for backwards compatibility for a while. Let's dig a bit into the idea and discuss what it would mean and expectations.

To support this feature we need to:

• Add serialization to all the data config classes in the FlexColorScheme package.

  • One of my reasons for not having it now in the package, is simply that so far it on purpose avoids using any 3rd party packages (packages not from Flutter or Dart team) or packages that I don't control myself. To deliver this feature, I may need to flex on this self imposed restriction for the package dependencies.

• With this in place we could add methods like FlexThemeData.fromJSON, FlexThemeData.toJSON and FlexColorScheme.fromJSON, FlexColorScheme.toJSON, at that point where you get this JSON file is up to the user. You could store it as a file in the project assets and read it from there or even read it from a server as a remote theme config for the app.

  • If you need to further in-app modify this created object, you can already do so on the FlexColorScheme object (and it sub objects) with their existing copyWith methods, and of course on the actual created ThemeData object with just vanilla Flutter ThemeData.copyWith. FlexColorScheme is really just a super fancy ThemeData factory, at the end of the day FlexColorScheme.toTheme and FlexThemeData produce a standard ThemeData object, but often a very complex one, that may take around 2000 lines of code to hand code.

• The Playground app would also need to support this new proper JSON format. Which would be fairly trivial to add when the FlexColorScheme package has support for it. It could retain support for importing then old "legacy" Playground only JSON format too, but going forward only export this new format shared with the FlexColorScheme package.

• Obviously the from/toJSON feature could also be used to persist entire theme configurations in whatever preferred storage. Shared preferences would e.g. be an easy choice for doing that locally. This would still no be the job for FlexColorScheme though, but adding an example on how to do it could be provided.

  • The Playground app would also be migrated to using this as its new local persistence model, as would the other sample apps. This would work well from the tutorial point on how to do it as well.

Thoughts?

Maybe in version 9?

I will put this on things to look into and experiment with in a separate branch. Not for the next release, or any 8.x release. Sounds more like something for version 9.

Planned next is adding a long list of new theming features to release 8, this in versions of 8.3 and 8.4. Have not really had much free time yet to work on release 8.3, only compiled a list of some things that may come to it https://github.com/rydmike/flex_color_scheme/blob/version-8-3-0/CHANGELOG.md

I'm also hoping to move the Playground build to a WASM build and new hosting that supports WASM (GitHub Pages where it is now, does not). I do have a working WASM build already of the Playground on new hosting. But while getting it working with WASM, a performance issue with strings in Dart WASM compiler was discovered, that made the code view page almost unusable. This has been fixed in Dart latest/master and will hopefully land also in next Flutter release (It is claimed to have been fixed and be fast now, I have not tried it, still need to do that too).

For version 10, my vision is actually a more or less complete rewrite of the Playground app. It's UI is getting a bit too complex for its own good. It was never intended to do all the things it does now, it was just a humble theming tutorial, as a last step and demo of what FlexColorScheme can do, but it kind of exploded.

More Playground history https://docs.flexcolorscheme.com/playground_history#background. Interestingly the import/export has already sort of happened 😃 I need to find time to update the docs site and restructure it too 😅

Export/import visibility

About the visibility of the export/import feature, good point!

Two options:

1. Try a version where it is at the top, together with the Theme code, even before it. It would then need to be in collapsed section, that is collapsed by default, so you can still see the theme code first. You would need to expand it to see the export/import function, but it would probably still be much easier to discover. Both could be in expandable/collapsible, code expanded by default and export/import collapsed by default.

2. Just add a new panel and own "Export Import" button below "Theme code"?

Thoughts? I can do either one already in the next release.

[MaxLap]

Thanks for the thorough answer!

Reading your response, I think you are trying to make a bigger solution than what I'm requesting here or misunderstood my goal/use case.

To clarify:

• I want a Flutter app to be able to generate the themes using the JSON that can be exported from the Playground.
• The only goal I have is to prevent Playground users from having to manually copy/paste store both the generated theme code and the playground configuration. Preventing risks of them going out of sync and maybe reducing merge conflicts chances (since there is only 1 file committed instead of two).
• I am not requesting for "any app should be able to generate the JSON required to load their existing themes in the Playground"

To fulfill my suggestion, the theme code can either be generated:

• When compiling or automatically just before the compilation. Not sure that is possible, I'm very new to all this tooling.
• Via a command line command which receives a JSON file and outputs a .dart file with the theme code.
• At runtime if that doesn't have some heavy performance cost

I've been doing Flutter for less than a month. I tried looking around a bit but I don't want to spend days dissecting it, so I surely don't understand all the subtleties and may be missing spots. But a quick implementation may look like:

• The goal is essentially to make

  flex_color_scheme/example/lib/example5_themes_playground/utils/generate_theme_dart_code.dart

  Line 16 in cf04dd0

  String generateThemeDartCode(ThemeController controller) {

  available in the core package.
• To make it work, we need the

  flex_color_scheme/example/lib/example5_themes_playground/utils/import_export_playground_settings.dart

  Line 164 in cf04dd0

  Future<String> importPlaygroundSettings(

• And to make that 2nd step work, we need

  flex_color_scheme/example/lib/shared/controllers/theme_controller.dart

  Line 45 in cf04dd0

  class ThemeController with ChangeNotifier {

  and

  flex_color_scheme/example/lib/shared/services/theme_service_mem.dart

  Line 24 in cf04dd0

  /// ThemeServiceMem implementations needs no init, it is just a no op.

Once you have that, all that is left is the dev experience of when does that run that I mention above. Some thoughts about them:

• The "runtime" mode means that instead of generating code, you need to actually set fields on objects. So the generate_theme_dart_code needs to be altered quite heavily from it's current "build a string" logic. Leading to a kind of duplication of functionality.
• The "runtime" may have a slightly bigger performance cost.
• The "must run a command" can be a bit annoying, but maybe it's easy for devs to add steps to their build pipeline in Flutter? If so, a few instructions on how to do that in the documentation may be a great way to achieve something close to the "When compiling" mode.
• The "must run a command" and "at build time" need to declare names for themes and class. This might need to be a new configuration in the playground. This is not needed for "runtime" mode.

Export/import visibility

Your first idea of moving it to top as a collapsed section is exactly what I had in mind. I feel there are already maybe too many panels on the side, so adding another one seems overkill.

You could also rename the panel to something like "Import/Export"?

Little FYI

In case you are not aware, the "Paste settings" button does not appear to work on Firefox. Maybe the clipboard handling is different / restricted. Is there a reason textbox isn't an editable field which would allow manual pasting.

[rydmike]

I want a Flutter app to be able to generate the themes using the JSON that can be exported from the Playground.

Yes, I understand that, but sadly the FlexColorScheme package will never be able to do anything useful with that JSON, it has nothing to do with the package. It is a construct that only works and exists within the confines of the Playground app.

To produce the result and feature you, and many other have has asked for as well, the FlexColorScheme data class and all sub-classes it uses, must be fully serializable to/from JSON.

Then FlexColorScheme package can then generate the JSON from its current config. Which I can then use in the Playground app as well to make a JSON of whatever config the Playground's FlexColorScheme object has at any given time, by using the same toJSON method. This file can then be exported, instead of the current hacked JSON used to export the current settings of all the UI controls in the Playground app.

We would instead be exporting the actual state of the FlexColorScheme data class object, that the UI controls make. This data class already internally produces the changing theme for the Playground app itself that you configure interactively. If FlexColorScheme can serialize it, it can produce a JSON config that can be use to restore this same config and state.

The hacked UI control serialization in the Playground would basically become obsolete, I would only keep it around to allow migrating old configs for a while. Also the Playground's tedious UI control persistence solution could then also be made a lot simpler.

---

The simplest way to use this export is of course to just save that file in the compiled code.

  const String themeJSON = 
"""
{the big JSON string exported from Playground}
""";

But you could also save it as a file in your project's assets folder, read it as string from there dynamically when app starts and assign it to a string. Likewise you could server from a web server if you like 😄

In both cases you can of course make many different configs and swap between them in your app as desired. To use it and make ThemeData you would do something like this:

MaterialApp(
   theme: FlexThemeData.fromJSON(themeJSON),
);

So you would not need to use any of the generated code, this would be an alternative way to use a config made with the Playground. I would still keep the code gen available too though.

Perf wise, yes decoding JSON is not without cost, but we can easily create finals of the decoded result, so that it is only ever decoded once during your app life cycle:

final ThemeData myLightTheme = FlexThemeData.fromJSON(themeJSON);

Then use that instead as your theme in MaterialApp.

The ThemeData object myLightTheme can of course be "modified" with copyWith, as can any ThemeData object.

However, if you want to make "modifications" on FlexColorScheme level after creating it from a Json, we could also do things like this:

final ThemeData myLightTheme = 
  FlexColorScheme.fromJSON(themeJSON).copyWith(appBarStyle: FlexAppBarStyle.primary).toTheme;

Basically use it as a FlexColorScheme object before making ThemeData, then you can use the FlexColorScheme APIs instead for configuring changes to the theme. Both work.

[MaxLap]

FlexColorScheme data class and all sub-classes it uses, must be fully serializable to/from JSON.

This is the part I don't grasp. When in the process is that needed?

To me, the process is:

1. Load the JSON (that the playground generated) in a ThemeController with importPlaygroundSettings. This uses nothing but the ThemeController and the JSON string.
   • The ThemeController only uses a ThemeServiceMem, nothing else that I see.
     • The ThemeServiceMem is a self contained class that uses nothing else.
2. Run generateThemeDartCode with the ThemeController that the data. This method also only uses the ThemeController.

So in my mind, those are the 4 parts that would need to be moved (or copied) into FlexColorScheme to enable the feature and nothing else. I do not see where in that process you need to touch the "FlexColorScheme data class and all sub-classes" and have them have full serialization support.

Either I missed an important part of the functions/classes I mentioned which uses them, or you are thinking of something bigger than I am (such as maybe some kind of 2-way transformation, where as I am only thinking of a single direction which is basically already coded).

[rydmike]

The ThemeController uses

import '../../example5_themes_playground/utils/import_export_playground_settings.dart';
import '../const/store.dart';
import '../model/adaptive_response.dart';
import '../model/splash_type_enum.dart';
import '../model/visual_density_enum.dart';
import '../services/theme_service.dart';`

Also the ThemeService is injected and the used implementation in the Playground is actually ThemeServiceHive. Not so relevant, more importantly the fields made for the Playground and its JSON are not directly the ones that the properties FlexColorScheme package uses. Sure, some are, as I refactored Playground to use more similar names before the 1st version of the schema was published.

They are still hand coded and based on the UI controls used in the Playground app and have nothing directly to do with the properties used in FlexColorScheme.

While you could do it they way you describe, it would create a maintenance nightmare and be very error prone. Also in a package, what would you do with the string that generateThemeDartCode? The code would be a String that you get when you run your program, only available at runtime, there is no reflection in Dart, you cannot magically use this String as runnable code.

We could make a builder companion package, and you would have to use build runner in your project to generate an actual file using the output from generateThemeDartCode, that your project picks up before you build it, just like Riverpod and many other pkgs do.

Then all the rather messy copied Playground code would be in a separate dev dependency like flex_color_scheme_generator package, but it would contain code that is very disconnected from the package itself.

The only sensible way to serialize and deserialize this, is if the FlexColorScheme package does it and owns it. Then its schema gets automated and it is always up to date and there is no need to hand maintain it. Maintaining the JSON hack used in the Playground as means to de-serialize its UI JSON and then make a code file from it, is very convoluted and not maintainable.

There would not really be any need to turn this JSON into code, as it can be converted to an object at runtime. It would of course be possible to write a method that writes a Dart config from the JSON, and I would probably do so, as it may be possible to automate it a lot too and remove all the hand tuned string code output made. This could be turned into a build runner package, but I don't really think there is any need for this in this scenario, as the static theme config could be gotten from the Playground and the fromJSON does the job if you want to skip the static code step for theme.

The serialization of FlexColorScheme classes would also be very usable in making its persistence much more maintainable in the Playground app too. It is currently a bit of nightmare already in the Playground to maintain, this all due to the app's history. As linked to earlier, it was never really planned and intended to be what it became 😄 So it has a some technical debt due to that, this serialization/deseriliaztion is one of those tech debt topics 😅

[rydmike]

Adding serialization to the FlexColorScheme package is actually not that of big thing do, but yes I need some deps in the package to do it. The way you described it would imo be much more challenging, especially with the build runner and all the code needed from the Playground in it, that should preferably then be shared with the Playground, which may create a version mgt challenge between them too.

I'm planning on going the other way with the Playground and remove it from the package into its own repo so I can develop on it without need to also always bump the package.

[MaxLap]

Alright, I get it now. Thank you for explaining. Didn't spot the imports and after 1k lines of scrolling in ThemeController seeing only assigns, I thought it was mostly just mapping setters to keys from the ThemeService. :)