refactor: adjust proposal creation #375
Conversation
| @@ -27,6 +28,13 @@ class _ProposalContentViewState extends State<ProposalContentView> { | |||
| void initState() { | |||
| super.initState(); | |||
|
|
|||
| _titleController.text = context.read<ProposalCreationBloc>().state.proposal!.title ?? ''; | |||
There was a problem hiding this comment.
IMO any time there's a ! that's a bug.
Generally - there may be exceptions.
Decide if proposal is always defined - if it is always defined, make it non-optional, meaning, it will always be defined in the codebase and at static compile time.
If it is nullable - then use ? and deal with situations where it's null.
The entire point of the nullable / non-nullable architecture is to force developers to think whether something can be null. This prevents the most prevalent bug out there, the null pointer exception. Using "!" gets around the architecture and should be done only as an exception.
There was a problem hiding this comment.
So in this case
Preferred solution is proposal is not nullable
Second best is use ? you're already handling this anyway in this code
| @@ -31,15 +31,15 @@ class ProposalReviewView extends StatelessWidget { | |||
| child: IntrinsicHeight( | |||
| child: BlocBuilder<ProposalCreationBloc, ProposalCreationState>( | |||
| builder: (context, state) { | |||
| final List<dynamic> jsonData = jsonDecode(state.proposal!.details!); | |||
| final List<dynamic> jsonData = jsonDecode(state.proposal.details!); | |||
There was a problem hiding this comment.
details! is still an issue - but I don't want to hold up the PR over this.
I think it's always defined.
There was a problem hiding this comment.
All proposal fields start as null except for type, which defaults to policy. As fields are progressively filled across views, they are all non-null by the review view.
Scope
This PR focuses on optimizing the
ProposalCreationBlocand ensuring that thekeyboardis dismissed when navigating between views on theProposalCreationPage.