Wishlist for Flutter in 2019
Flutter is awesome. Here are some things that I believe will make it even more awesome.
I went to DartConf 2018 with no serious expectations for Flutter — just a willingness to learn. I left with a strong desire to see it flourish and mature beyond mobile platforms. Seeing how React Native has flourished over the last few years, I strongly believed that Flutter could do the same and make a compelling argument towards Dart’s dream of being the best client-side language.
This year my enthusiasm has increased dramatically. With a clear picture of how Flutter plans to move beyond mobile platforms to desktop and the web, my expectations have as well. Here is my wishlist for improving the Flutter ecosystem and framework in 2019.
1. RFC (Request For Comments) process
This may not be the most important feature from a technical or developer ergonomics perspective, but I am starting with an RFC process because I think it offers a clear path for the design and adoption of some of the other items on this list.
If you are not familiar with the RFC process, there’s an excellent writeup on React’s blog that describes it and why they adopted it. To summarize the steps:
- Create an RFC document detailing your proposal.
- Submit a PR to the RFC repository.
- Incorporate feedback into the proposal.
- After discussion, the core team may or may not accept the RFC.
- If the RFC is accepted, the PR is merged.
- Once merged, any contributor can submit a PR implementation for review.
Specific features that React used the process for such as the new Context API and Hooks (stay tuned) highlight its primary use cases:
- Proposals that create a new API service area
- Proposals that remove features already shipped
- Semantic or syntactic changes that are not bugfixes
In some scenarios, such as a major API change or a new convention that would benefit from an in-depth review, a simple GitHub issue isn’t the best collaboration point. Beyond that compare a normal template of a GitHub issues page to Ember’s very straight forward RFC site. Each RFC has a very in-depth summary, motivations, and a detailed design with examples.
There are several notable open-source projects currently using the RFC process with great success:
What is immediately noticeable is there is very little variation between each process. If you are familiar with one process, then you are basically familiar with them all. They introduce consistency in a public and visible way. Whereas each of these projects has its own way of managing issues, the RFC process is easily recognizable because it has very focused goals.
Ironically, I had been thinking about this long before The Boring Flutter Development Show’s episode on Influencing the Flutter SDK. It is important to note that this proposal is meant to extend the processes that open-source projects already follow, not replace them. GitHub issues are still useful for identifying bugs or work items in the ways described on the show. All three of the following items of this list would be great candidates for RFCs.
2. Simpler Inherited Widget/Context pattern
I had to read quite a bit of article and examples to fully grasp how InheritedWidget worked in Flutter. The concept itself was not foreign to me coming from React, it was just a bit less straightforward and more verbose. Let’s take the simplest example that I could find.
I am sure there may be simpler examples in the wild, but most of the articles I’ve read are consistent with what we have above so let’s go with it. Now let’s compare that to a similar implementation in React.
These examples are essentially doing the same thing — defining some state that should be shared and passing it to a provider. But I prefer the React version because it abstracts away the complexities.
Currently, if I had to choose between using or recommending InheritedWidget vs. something like Brian Egan’s Scoped Model or Remi Rousselet’s Provider libraries, I would go with the latter. That is because these libraries abstract away much of the complexity that the developer may not care about. For the simple use case of sharing some state in multiple places in the application, I think that the need for these libraries diminishes significantly if we have a simpler, more concise API.
3. Function widgets
This is probably the most selfish item on this list, given my inclinations towards functional programming and avoidance of OOP until it is absolutely necessary. There are many different arguments for functional programming that I won’t bore you with. Having worked with Vue & React, there is an elegance to being able to represent UI in a component driven framework using plain functions. Let’s look at a class variation of a widget and compare it to a function variation.
I prefer the latter because of its simplicity. It’s easy to read and there’s less visual noise (I admit this is an subjective opinion but it’s one that most functional programming enthusiasts will agree with).
I am aware that classes are important in Flutter because of how they are able to be optimized. I think a solution could easily be added in the same way that Flutter & Dart teams offer generator solutions for dependency injection and JSON serialization.
In fact, Remi Rousselet’s functional_widget offers a great POC for this concept.
4. Hooks
Keeping the theme of adapting some popular features old and new from React, I am possibly even more of a fan of the idea of Hooks in Flutter than Function Widgets.
Hooks are a new primitive being introduced in React for handling state logic. Hooks allow you to reuse stateful logic without changing your component hierarchy and allow you to sleep peacefully at night while avoiding “wrapper hell”. The closest thing to a Hook that exists in Flutter is the static method Theme.of that allows you to retrieve the app themes from context. The following widget(s) represent my fever dream.
Above we have a very different take on the example we get when we run flutter create in the terminal. One where the main home page is a Function widget and the state of the counter can be updated without any differentiation between Stateless/Stateful widgets. I simply call the count function with no parameters to get the value, and I call it with the new count when I wish to update the count. The biggest benefit Hooks offer is the colocation of code. I am no longer required to bounce around a single widget or multiple widgets and functions to understand the implementation because it’s co-located in my Function widget.
Having worked in a very large and complex project in React, I immediately saw the applications for Hooks and how they would simplify some of the most complex areas in the application. I imagine they could have a very similar impact in Flutter.
A couple of good POCs for this concept are the always active Remi Rousselet’s flutter_hooks and Alfredo Salzillo’s flhooks
Community challenge: more contributions
The JavaScript ecosystem has flourished because of its community as much as because of the evolution of the language. The Flutter community will only continue to grow and it is dependent upon us as both contributors and consumers of open-source software.
My challenge to both the community and myself is that we build each other in whatever way we can, be it thru development, monetary contributions, or just simple encouragement.
Conclusion
Flutter has some very aggressive aspirations, and I think some of these wishlist items can help further them. At the very least I firmly believe that an RFC process will inspire collaboration and that Function widgets and Hooks will improve the developer experience dramatically. My hope is that when 2019 is concluded, I’ll start the next year with a whole new wishlist.
Sup?! I’m Ryan Edge. I am a Software Engineer at Diligent Corporation and a semi-pro open source contributor.
If you liked this article, be sure to follow and spread the love! Happy trails
