Flutter for React / React Native developer

The article is enlightened for those who write on the React / React Native stack and want to master a new technology for themselves - Flutter. And no, we will not write an application here on this framework! If you are waiting for another Todo List, this material is not for you.



image



Rather, this is another story about how I switched to a new framework) The



material does not imply the ultimate truth. Here are described only those solutions that I chose for myself, and which for me, having a huge background in React & React Native development, it was easiest for me to apply on a real project.



Context



To begin with, I will describe, so to speak, the context. An order has appeared - to write a small (about 15 screens) cross-platform mobile application. Naturally, out of habit, I started doing it in React Native. In two weeks, the application was implemented by about 80%.



On the weekend I read another article from Surf on HabrΓ© with the results of the survey. And the thought came, why not try? Will I be able to repeat what has already been written on a new framework for me? It was decided to spend the weekend trying this. As a result, over the next week, not only the 80% that were before, but also the remaining 20% ​​were rewritten. development time has been reduced by more than half!



pros



First of all, the advantage is the speed of the layout. Screens rivet VERY fast. Linear gradients, svg, gif - pretty much all out of the box. Overlapping components ( position: absolute ) - no problem at all. Anything that caused pain in React Native is done with a snap of your fingers. Animations are generally a fairy tale! A lot less time was spent on the same screen with constantly animated components with Flutter.



Minuses



There are two tangible drawbacks. The first is documentation. Very little in Russian. Official English is not very well structured, yes, it gives a lot of useful code examples, but it is difficult to understand something sensible from the general architecture of the application.



The second disadvantage is the packages. There is still a complete mess there. Choosing a really good package for the one you want is not a trivial task. Somewhere one feature does not work, somewhere else. A lot of time is spent on selection. As an option - add something yourself, but this is when I get used to it)



Experience: hooks



My acquaintance with React dates back to the days when normal classes had just appeared in it. Now I can't imagine him without hooks and have already forgotten about classes. For flutter, there is a wonderful flutter_hooks library that allows you to bring familiar hooks into your project. For me, it completely replaced StatefulWidget . There are a lot of hooks, you can write your own, but most often useEffect , useState and useMemoized are used in my code . For animations, useAnimationController .



Maybe this is not the best solution (I'm ready to read about the cons in the comments), but it allows you to use the background from React in a new framework for yourself. I don't even see any reason to give examples with code - all React developers know this as our father!



Experience: state management



At one time, I had to work with redux , and with mobx , and even, with exotics, such as storeon . It seems that it (redux / mobx) is also under Flutter, but, frankly, I did not master it). In my opinion, everything is too complicated there compared to what was in React. You can, of course, spend more time and figure it out, but why, when I found a better solution: riverpod .



A library from Remi Rousselet , author of flutter_hooks - naturally they both work nicely). In fact, it is a modified Provider . Just add to your runApp ( ProviderScope (...))wrapper over everything else and get the global scope throughout the application, accessible from any widget. It is enough to write useProvider ( providerName ) in the build method of HookWidget and we have available data from the specified provider.



There are many provider options in the library, but the most basic are ChangeNotifyProvider and StateNotifyProvider . All business logic can be safely removed from widgets and transferred to these providers. Moreover, they are perfectly combined with each other and it will not be difficult to get access to the methods and data of the other from one.



The pattern is very similar to redux ducksthe approach that, to me personally, has become the closest in the world of React. Only "ducks" are smaller. The main thing to remember here is that it is better to have many small providers that will be used in different widgets than one large one for them, because those widgets that have actually been changed will be redrawn.



Disappointment: web



After the overwhelming (for myself) success with the development of a mobile application, like any self-respecting full stack, I decided to touch Flutter for web. Again, rewriting one of the really working corporate applications.



Of course, flutter web is still in beta, and everything described below applies specifically to the beta version. I really hope that with the release a lot will change for the better. Nevertheless, Flutter disappointed me here.



The first thing to know about Flutter Web is not about websites, but about applications! Those. it is necessary to write in the same way as for mobile. All widgets are the same. You cannot use third-party JS in your code. Only access it via dart: js . Accessing html also via dart: html... This cuts off almost everything that has already been done in the web world at once. If you want a cool animation that has already been implemented somewhere in css + js, you can't do it , write an analog on flutter or use dart: js, which is not always easy. It's impossible to painlessly use a ready-made JS / css library.



The second minus is the packages again! Although on pub.dev most of it is marked as supporting both web, android, and ios, in fact, either one or the other usually works. Those. you won't be able to create a completely cross-platform code.



Packages for the web are usually a wrapper over their js counterparts. But almost always they don't keep up with the version of the package they are wrapping.



Example:



The task is to make authorization via MS and receive user data.



In good old JS, everything is simple: take msal andmicrosoft/ microsoft-graph-client - and enjoy the result. Find msal_flutter in



Flutter , connect it ... and it turns out that the web package does not support it. Okay, we find msal_js - this is a wrapper over the usual msal, so you need to include it in index.html via the good old script tag. But if msal has already been updated to 1.4.2 then this package supports a maximum of 1.3.0! Well, well, we got the token in half with grief, what about the user data? There is a package microsoft_graph - no documentation on it. To find the required method, you need to go into the package code and poke around there. And to find out in the end that only a couple of them are implemented there for working with tasks! Find another msgraph



- so that generally the only method supports!



Fortunately, the protocol itself is not very complicated there and you can quickly write something of your own when you need to work and not write libraries)



Environment



The third and biggest disadvantage is the impossibility of setting up the environment. Flutter web runs either in a browser or as a web server. You can still set the port on which it will spin through the command line parameters (which is also not very convenient, where is the config ?!) But how can I run it as https with a self-signed certificate? So that at the same time the hot load will work and debug and other chips that usually work? Hello! Guys, 2k20 ends, and you still have http? Really?!



Conclusion



Definitely, Flutter as a framework for cross-platform mobile development is tearing React Native to shreds on all fronts. I am satisfied, the customer is also delighted - what else do you need?



But as a tool for writing web applications, it is still damp and too laborious. Get ready that where you connected a third-party js package in a couple of seconds, here you will write a wrapper for it for a couple of days, or even your own analogue on Flutter.



PS



I will repeat it again for those who forgot from the beginning of the article. The applied solutions and conclusions I described are the conclusions of a person with a 1 week background in Flutter and a 3 year background in React. So do not take them for the ultimate truth. I am ready to discuss in the comments with the guru what I did wrong.



All Articles