Null safety

[Overman775]

Thanks for the package. Are you planning a release null safety version?

[OndrejKunc]

Hi, thanks for opening the issue. I have already started working on it in a null-safety branch.

So far I have migrated only expression_language package, but hopefully, I will have some free time to finish it soon.

[OndrejKunc]

It has been a longer time than I expected so here is some update:

It turned out the null-safety migration is a much bigger challenge than I expected. What makes it so difficult in this project is the fact, that the expression_language basically defines its own type system which is quite unique feature compared to most packages on the pub.dev.

That's why I had to make a decision if I want to allow using nullable types in the expressions and on the components properties. So far it looks like using nullable and non-nullable types side by side is the most flexible solution.

What it means: You can define either Property<int> x , or Property<int?> x on your components. If you use the nullable property you can check for the null in the expression, something like:

"expression": "isNull(@component.x) ? 0 : @component.x!"

Notice the operator ! at the end which works the same way as in the dart and will convert the nullable value to non-nullable.

Unfortunately, all those changes require a huge amount of work touching almost all the files and implementing a lot of new code just to have this support.

The good news is that the exppression_language and dynamic_forms packages are almost ready (I will just add more tests). My hope is that other packages that are built on top of those two won't introduce such a difficult challenge and would be more straightforward to implement.

[markphillips100]

Hi @OndrejKunc . I know you are actively working on null-safety which is cool. I created a fork to see if I can continue the other projects refactor - I had an urgent need.

All the projects run as "sound null safety" now but I haven't used them in my app. The examples do work though.

I wouldn't suggest a PR as there's too much collateral change (to support the inter-package refs to my branch for example) so I only present it as a way of helping should you need it. It's also possible I haven't used the language feature correctly in places and that also would have unintended side effects. For example, I modified the generator to support nullable types but that led to the model generated code needing to change as shown here. The original didn't need a cast so not sure if I did something wrong. It works but feels wrong. Hope you have better luck.

Obviously as soon as your null-safe lib is released I'll swap over :-)

[OndrejKunc]

Hi @markphillips100 , I just started migrating the generator project yesterday, but I didn't get too far yet.

Looking at the code it looks like it might be exactly what I wanted to do! Especially the generator grammar part where you added the ? token the same way I intended. I think the casts are now necessary since the new dart version is more type-safe so there is probably no other way. I will definitely check it out in more detail and probably reuse a lot of your code (if not all) if you don't mind :)

I am very happy you made it work, so others can use your fork until I finish the migration at my really slow pace. Good job! 👍

[markphillips100]

No problem at all. Glad to help.

[OndrejKunc]

I just merged the Null Safety functionality into the master branch and published it on the pub.dev. Since it is a major release, I decided to bump versions of all the packages to 1.0.0.

I hope everything will work as expected. I tried to describe the changes in the CHANGELOG.md of the individual packages. Thank you @markphillips100 for your work, I used a lot of code from the generator package in your fork.