Example Project

[WieFel]

• Example project using null-safety

[WieFel]

[calvintam236]

@WieFel can you pull from master and update the import here (package:tinycolor2/tinycolor2.dart)?

[calvintam236]

1. flutter format needed
2. merge from master

[WieFel]

Ok, apparently something went wrong on my rebase before.
I'll just rebase again and force push...

[calvintam236]

1. remove pubspec.lock from example directory. it is only needed in the repo root for package
2. flutter format for the whole example directory

[calvintam236]

Ok, apparently something went wrong on my rebase before.
I'll just rebase again and force push...

btw this is feature branch. it will just squash into one.

[WieFel]

1. remove `pubspec.lock` from `example` directory. it is only needed in the repo root for package

After removing it, it is regenerated when running the example app. So I think it has to be there... It could be added to .gitignore, but I don't see a reason why it should not be commited...

2. `flutter format` for the whole `example` directory

Done. No changes at all. Everything was formatted fine.

[WieFel]

btw this is feature branch. it will just squash into one.

Yeah I know. But rebasing keeps the branch network cleaner in my opinion. Also if it is only for the moment...

[WieFel]

What we still have to discuss is this: #2 (reply in thread)
Let's open a separate discussion topic about example/demo project!?

[calvintam236]

1. remove `pubspec.lock` from `example` directory. it is only needed in the repo root for package

After removing it, it is regenerated when running the example app. So I think it has to be there... It could be added to .gitignore, but I don't see a reason why it should not be commited...

https://dart.dev/guides/libraries/private-files

[WieFel]

https://dart.dev/guides/libraries/private-files

https://dart.dev/guides/libraries/private-files#pubspeclock
For the example project it is fine to have pubspec.lock. We should rather ignore/remove the one in the project root.

[WieFel]

@calvintam236 ok like this? Wanted to keep it as simple as possible.

[calvintam236]

@calvintam236 ok like this? Wanted to keep it as simple as possible.

Shouldn't the rest using c. since you have var c? (BTW don't use var. Specific the type)

It would be great if you can add other constructors such as .fromRGB and .fromString

[WieFel]

Shouldn't the rest using c. since you have var c? (BTW don't use var. Specific the type)

What do you mean? All the list items DO use c.
And ok, I can specify type...

It would be great if you can add other constructors such as .fromRGB and .fromString

Ok

[calvintam236]

Shouldn't the rest using c. since you have var c? (BTW don't use var. Specific the type)

What do you mean? All the list items DO use c.
And ok, I can specify type...

It would be great if you can add other constructors such as .fromRGB and .fromString

Ok

I mean in the screenshot. You are using Colors.blue.xxx in all of the example.

[WieFel]

Yeah, that is an example for the extension usage in a static way.
Of course it could also be c.color.lighten(20) for example, but that's almost the same as c.lighten(20).color. Don't know which way is better!?

[calvintam236]

Yeah, that is an example for the extension usage in a static way.
Of course it could also be c.color.lighten(20) for example, but that's almost the same as c.lighten(20).color. Don't know which way is better!?

Personally, I use TinyColor() over extension because it will not create another instance of Tinycolor. I think the extension way is convenience but has performance penalty. It is basically a stripped-down version.

[WieFel]

So, should I change Colors.blue.xxx to c.color.xxx?
In my opinion it should stay Colors.blue.xxx.

[calvintam236]

So, should I change Colors.blue.xxx to c.color.xxx?
In my opinion it should stay Colors.blue.xxx.

you can add another example for original color Color c = Colors.blue; and use c. for all of the below. it is clear either works