Playground: Allow to import the theme code or something to keep editing the theme in multiple devices or in future.

[MiniSuperDev]

Hello, Like you allow to copy the theme code, it would nice to have a way to import the config to allow edit the theme in the playground in multiples devices or in future if a person want to change something, He only upload or import the current config, and he can continuous editing in the playground.

It should also support all the custom modifications that have been made to the properties, it does not mean that you have to have an interface to edit them if they are not currently in the playground, but it does mean that they are used and when exported they are also there.

Thanks

[rydmike]

Just to give some feedback on this. Yes this is something I have thought about as well and want to do, but ultimately any good solution for this really requires a back-end and sign-up, so you can store a number of different named configs, that potentially could be shared with others too.

I do have this on the roadmap for a major rewrite under code name "V10".

[akiller]

This would be a really useful feature. I find your theme playground an excellent way to help visualise how everything looks and to help decide on which widget to pick in a particular situation.

Just to give some feedback on this. Yes this is something I have thought about as well and want to do, but ultimately any good solution for this really requires a back-end and sign-up, so you can store a number of different named configs, that potentially could be shared with others too.

I do have this on the roadmap for a major rewrite under code name "V10".

One suggestion is that I think ThemeData and ColorScheme could be base64 encoded and added to the playground link and decoded/restored from this. This wouldn't require any backend work as it would be all in the front-end.

This link could be generated from the playground editor which you could copy into your code/documentation in order to restore the theme in the editor. E.g.,

https://rydmike.com/flexcolorscheme/themesplayground-latest/?themeCode=abcd&colorScheme=zxyz

I don't think there's any real limit on querystring length, but you could be smart and save the schema as a minified JSON before base64'ing it to save space, e.g.

light: {
  s: materialBaseline,
  sm: levelSurfacesLowScaffold,
  bl: 7,
  st: {
    bol: 10,
    boc: 0,
    utt: 1,
    m2im3: 1,
    add: 1,
    uidtid: 1,
  },
  cs: comfortablePlatformDensity,
  m3: 1,
  slom3: 1
}

It would base64 as something like:

bGlnaHQ6IHsKICBzOiBtYXRlcmlhbEJhc2VsaW5lLAogIHNtOiBsZXZlbFN1cmZhY2VzTG93U2NhZmZvbGQsCiAgYmw6IDcsCiAgc3Q6IHsKICAgIGJvbDogMTAsCiAgICBib2M6IDAsCiAgICB1dHQ6IDEsCiAgICBtMmltMzogMSwKICAgIGFkZDogMSwKICAgIHVpZHRpZDogMSwKICB9LAogIGNzOiBjb21mb3J0YWJsZVBsYXRmb3JtRGVuc2l0eSwKICBtMzogMSwKICBzbG9tMzogMQp9

Thanks!

[rydmike]

Sure, that and saving as file too, both can certainly be done and I will do them before adding a backend.

Still there is a reason why it is not there yet an dit has to de with the humble beginnings of the Themes Playground. It was only ever supposed to be used as small tutorial on how to use FlexColorScheme and not the wild thing it is today 😃

More info here and via link to docs comment in the discussion #250

Plus a related issue: #141

[akiller]

Sure, that and saving as file too, both can certainly be done and I will do them before adding a backend.

Still there is a reason why it is not there yet an dit has to de with the humble beginnings of the Themes Playground. It was only ever supposed to be used as small tutorial on how to use FlexColorScheme and not the wild thing it is today 😃

More info here and via link to docs comment in the discussion #250

Plus a related issue: #141

Oh yeah I definitely understand the pain of feature creep 😊.

I had a play around with an idea and added a comment to #250 which is basic working proof of concept to get a theme to export.

[rydmike]

Hi @akiller,

Thanks, awesome and yes this would be very welcome and is in line with what I was thinking of doing as well, once I get version 8.0.0 to final release and out first.

If you want to take a stab at getting this prod ready and providing a PR, that's even better.

I won't be merging it to the V7 line, as it is dead anyway, Flutter 3.22 basically broke quite a few of its theming features, so after a few more Flutter releases it is history or legacy anyway. Still slightly annoyed that Flutter 3.22.0 broke 249 of its own test and just silently fixed them, for theming it has been so much rework.

All work on release 8 is in this branch: https://github.com/rydmike/flex_color_scheme/tree/version-8-0-0

The current repo master branch is the current pub stable release (7.3.1), and I won't be doing any updates to it.

Currently on V8 I'm focusing what little time have on getting all the testing for the package up to snuff again before releasing it as a stable release. There is a first dev release of it out https://pub.dev/packages/flex_color_scheme/versions/8.0.0-dev.1

Since this addition is not touching anything to do with the package, just the example5 app, I don't have any problem at all adding something as nice and asked for like this to it.

All the types it should handle can be found here:
https://github.com/rydmike/flex_color_scheme/blob/version-8-0-0/example/lib/shared/services/theme_service_hive.dart#L69C2-L96C4

If you make a PR please do so to the version-8-0-0 branch.

I like the simple copy/past from a field, no need to mess with file/import export on all platforms, should work great as first version at least.

Try to make it as robust as you can, so it just skips things it cannot parse, and maybe a log you can see of what it could not parse.

I've been known to edit/update both the controller prop names and key values now and then in the storage service too. Should probably do a review of them for this to make sure they are all "sensible" and preferably all match too. So there is no itch to tweak them later and break this for that reason.

If you get all this up to snuff, we can totally include it in V8 stable release and do some updated dev builds to test it out first of course.

---

Yeah I still see the Themes Playground as a bit of the "example5" tutorial on how you can create a dynamically themed apps with FlexColorScheme, which is what it started as and kind of still is.

When I start working on V9 I'm going to break out the Themes Playground to its own repo and refactor it to something more sensible when it comes to its architecture so it can scale features a bit better an faster. I'm surprised though how far it got with its simplistic approach, not at all intended for what it is today, it is basically the same as example 3 and 4, just "more" dynamic theming props.

[rydmike]

Some potential gotchas:

• runtimeType is not guaranteed to work, especially not if you obfuscate the build, but since there is no plan to do that, should be fine. But no idea how it works on WASM builds, I have not looked into that.

• When I do migrate the app to a new architecture the entire current theme controller and storage services will be gone. There is no reasonable way to move this export/import to the planned changes, or at least I was not planning on supporting it. This is another reason why I did not want to do this before making the architecture refactor. As it is one more migration headache 😅

[akiller]

Hi @rydmike,

Thanks for the comments!

I should have thought to have not done it on v7, nevermind. I've copied all the changes onto the v8 branch and with some tweaks it seems to work fine still.

Thanks for the link to all the adapters. I've gone through and removed the runtimeType and instead handled each one manually. And as suggested, any types which are unknown to the importer/exporter should now just be ignored and logged out (to debugPrint).

I've pushed the changes to a new playground-theme-export-v8 branch should you want to have a look before I send you a pull request:

https://github.com/akiller/flex_color_scheme/tree/playground-theme-export-v8

When I start working on V9 I'm going to break out the Themes Playground to its own repo and refactor it to something more sensible when it comes to its architecture so it can scale features a bit better an faster. I'm surprised though how far it got with its simplistic approach, not at all intended for what it is today, it is basically the same as example 3 and 4, just "more" dynamic theming props.

When I do migrate the app to a new architecture the entire current theme controller and storage services will be gone. There is no reasonable way to move this export/import to the planned changes, or at least I was not planning on supporting it. This is another reason why I did not want to do this before making the architecture refactor. As it is one more migration headache 😅

Oh no, I guess that's a future problem thankfully!

If you're looking for a different database I find Isar (https://github.com/isar/isar) to be great. It's by the same guy who made Hive but it's much nicer to use, and from what I understand Hive will eventually be replaced by it.

And I also really like using the freezed package (https://github.com/rrousselGit/freezed) to help generate all the boring boilerplate code, but I guess it depends on what you need to do.

[rydmike]

Awesome, looks good to me. Did not build it though, just reviewed it on GH. Maybe some gotchas I'm not thinking of now, but if so, we can deal with it after.

Feel free to submit a PR to branch version-8-0-0.

Test are still broken in hordes on version-8-0-0 for the package, but I don't think a PR to the branch version-8-0-0 should trigger my action to run them.

---

Yes I know of Isar and the author, I've used an early version of Isar years ago. Sadly it has not had a lot of work recently, and its Web support has been in question, for long it did not work, it did not save anything, not sure where it stands now. No idea about its WASM support.

I'll probably go with Drift, used it with great success too and it supports WASM.

Freezed is great, but to be honest I prefer dart_mappable, it even has some advantages over freezed, plus I think its syntax is more elegant, feels more like a part of Dart. I converted 45 data classes from Freezed to Dart Mappable in a project 😄
https://pub.dev/packages/dart_mappable.
I have met both authors, both are terrific and brilliant, and doing awesome work for the Flutter Community.

As for adding a backend to the Playground (much) later, nothing is set in stone, I was first thinking of just slapping Supabase on it, but lately I kind of want to try Serverpod.

[rydmike]

Been fighting a nasty usage edge case bug in the V8-dev.1 version of the package, discovered it while fixing tests and getting them up to snuff again. Nothing that concerns the Playground plus the use case is so exotic I doubt anybody uses it and will run into, but it it is not working to spec in that particular edge case, trying to figure out what the best approach will be, but enough for today. Look at it with fresh eyes tomorrow.

[akiller]

Awesome, looks good to me. Did not build it though, just reviewed it on GH. Maybe some gotchas I'm not thinking of now, but if so, we can deal with it after.

Feel free to submit a PR to branch version-8-0-0.

Test are still broken in hordes on version-8-0-0 for the package, but I don't think a PR to the branch version-8-0-0 should trigger my action to run them.

Fortunately I rarely get around to writing tests 😄.

Yes I know of Isar and the author, I've used an early version of Isar years ago. Sadly it has not had a lot of work recently, and its Web support has been in question, for long it did not work, it did not save anything, not sure where it stands now. No idea about its WASM support.

I'll probably go with Drift, used it with great success too and it supports WASM.

Oh interesting. ISAR v4 is meant to be a major upgrade which is still in development but probably not too far away and I believe that will support web.

I've never used Drift, will have to look it up.

Freezed is great, but to be honest I prefer dart_mappable, it even has some advantages over freezed, plus I think its syntax is more elegant, feels more like a part of Dart. I converted 45 data classes from Freezed to Dart Mappable in a project 😄 https://pub.dev/packages/dart_mappable. I have met both authors, both are terrific and brilliant, and doing awesome work for the Flutter Community.

As for adding a backend to the Playground (much) later, nothing is set in stone, I was first thinking of just slapping Supabase on it, but lately I kind of want to try Serverpod.

I'll have to check those out too! I agree the freezed syntax is pretty ugly and really easy to get wrong though, but it does work well.

PR incoming!