Tag: #Dart

Story Stains: Frontend

Another post about building Story Stains, the previous one can be found at "Story Stains: Backend".

Flutter

Last year I took a in Angular from Udemy, but for this project as Angular appears to be slowly dying, I decided to use another possible Google dead-horse, Flutter.

This time I didn't use a book, or tutorial or such to start building the application. For one, I couldn't find a good up to date tutorial and I somehow expected a quite prescriptive development environment, which was not what happened. In retrospect, I think building the app as a pure HTML/CSS website first could have been quicker. Perhaps that's what I'll do for future projects, or even for this project's web frontend later.

From my anecdotal experience so far, Flutter appears to have a lot of developers from Asia and South America, unlike other tech communities heavily focused in the US. The community also feels smaller than rust considering the number of Medium articles or blog posts. Sometimes that's useful, as there are fewer answers to your googled questions, but sometimes annoying as they can not fit into your specific use case.

At the beginning I would take examples from the Flutter Cookbook, but I still ended up using an example project from f and CodeIdeal's realworld example for a larger architecture example. When I started trying to make the UI look like my sketches, I checked examples from the Flutter Gallery.

I didn't expect the level of complexity there is for frontend development, but there are several layers: Loading from the network, state management, User interface logic and the displaying UI. I have more respect than before for UI developers since there are so many decisions to be made. One of the first in Flutter is choosing from loads of state management libraries. I started with GetX but struggled with the lack of documentation and eventually swapped to using just the provider package. It seems like [Riverpod(https://riverpod.dev/) is becoming somewhat of a replacement for provider and should be looked out for.

Even with the new to me complexity, I'm still quite impressed with how easy it is to build in Flutter. From my git logs, it took me from 30th May to 9th June to with no flutter experience to have authentication, create, edit and read my initial API. With the material UI as an initial basis, it doesn't look like a dog's dinner either.

Some other problems are the lack of testing and documentation for all but the larger packages on pub.dev. Most examples written in blog posts, also lack tests. It can be a problem when looking for good test examples outside of the main Google supported packages. Many tests took me a long time to write, simply because I could not find a good example for a particular widget or provider. I'm also not sure about a sensible testing design pattern with the provider package, many tests I end up mocking unrelated providers simply so they don't fail on construction.