Feat/commitments form

[dromerolovo]

Working UI with CommitmentsBloc integration.

The purpose of this PR is to consolidate all sections of the form to prepare for the following changes:

• Review and implement the form controllers with their respective validation and factory method
• Implement the integration between all the sections of the form and the bloc
• test the repository with the CrowdAction provided by the form.

[github-actions[bot]]

Visit the preview URL for this PR (updated for commit 4b115d7):

https://collaction-development--pr68-feat-commitments-for-qx313k9f.web.app

_{(expires Sat, 22 Apr 2023 00:46:05 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 2cf09e8dbf51d2eab3fc6679b673d248bc8047bb}

[dromerolovo]

@andre-tm-hui

The thing about point 2 is that it can be frustrating for users if they want to delete all values and then add another. Currently, the behavior is a bit odd also because the last value is added when there are no values after expanding or contracting the CommitmentItem. This happens because the validation is producing an error, and the updated values are not stored in the bloc. So the last values are fetched again from the bloc. To address this for now, we could pass 'true' in the buttonTriggered parameter so that error messages will be displayed if the field is empty. Then, we can come up with how to maintain the state if a field is empty.

Regarding point 3 I think that there is more common to be able to write incorrect values, that not having the possibility of writing, take as an example EasyApply form in linkedin. You can write letters in numeric fields and of course you'll get the error message.

Regarding blocks, it might be cases that block A could block B and the other way around, shouldn't be a problem.

Regarding your last point, Yes definitely, we should add injection.config.dart for example.

[andre-tm-hui]

I think if the weird behaviour could be fixed, that solves 2 and 3 automatically - the most jarring thing with that part of the UI is that the tick/indicator of a commitment's validity changes correctly if a field becomes invalid, and stays correct when the commitment is closed. However, when you open that commitment again, it suddenly becomes valid.

For now, passing buttonTriggered as true seems good enough though.

[dromerolovo]

I think if the weird behaviour could be fixed, that solves 2 and 3 automatically - the most jarring thing with that part of the UI is that the tick/indicator of a commitment's validity changes correctly if a field becomes invalid, and stays correct when the commitment is closed. However, when you open that commitment again, it suddenly becomes valid.

For now, passing buttonTriggered as true seems good enough though.

Yes, Agree. And That's happening because of what I explain in the previous comment, when I made a reference to the point 2. I'll think of a solution and create a separate issue because is not critical, just weird.