I’m back, in October I was on vacation, so I decided to make the most of it and I took a break from the routine, I was going out of a frantic routine, I kind of needed it, I was about 3 weeks without opening VSCode hehehehehe 😬.
Buuuuuut that does not mean that I was stopped, during the holidays I enjoyed and went to the 3rd edition of React Conf that happened in São Paulo on October 19th, 2019, and this is what I came to tell you a little about the things that I saw it there, but in a nutshell.
Andrei Calazans, who is a highly regarded guy when it comes to React Native, has brought some of the comparison between React Native and his “enemy” Flutter.
But Flutter is not far behind, after Nubank(a bank that operates in Brazil) decided to join it, it has grown enormously in the Brazilian market. There are great advantages of it over apps made in React Native, and vice versa, so, as André made clear, it’s a matter of knowing what the purpose of your project is, so that you decide what technology to use, but Always aware that no matter what choice you make, you will not be left behind.
Particularly, during the talk, I understood that for performance reasons, Flutter is a little, but very little, ahead of React Native, but the React Native community knows this, and they are working to improve this issue even more.
Performance with React was a very interesting talk hosted by Larissa Thaís, which makes us think 2, 3 or 4 times about the projects we are working on or are working on.
She begins by asking, “Does your system do well?”
But within that question, there are other questions…
Calm down, come on, if your answer is positive to all of these questions below, you are on a super right path.
- Does your project have a favorable Loading Time?
- Does your project have a good flow?
- Is the bundle size good?
- Does it work correctly? No mistakes?
- Is the error response time for the user fast?
- How good is it when displaying multiple items on screen?
- Does your project enable you to do more in less time?
- Have a steady stream of new users?
These are very important questions that you should always be asking not only at the end of the project, but all the time if you have made a new feature, re-ask these questions, which I am sure will help you.
Again, she asks, But why bother me with this (performance)?
She highlights 2 interesting topics about this question and I will explain why, which are:
“Performance influences user perception of quality”.
That is, if you have a fast and performative system that when a user needs to perform a particular action, he simply goes there and does, without delay, without prolonging, the user has a very positive view of the product company. The system does not have to guess what the user will do, it just needs to do it.
“You won’t have a user saying,” The reporting page is taking too long because of the images.”
Easy peasy yeah? if the problem came with the solution half of our programmer service would be ready. To rephrase, the user would just say: “̶E̶h̶i̶s̶ ̶f̶u̶c̶k̶i̶n̶g̶ ̶s̶y̶s̶t̶e̶m̶ ̶i̶s̶ ̶s̶h̶i̶t̶” … “This system is too slow”
To be more straightforward, she outlines some tips for making an objective analysis, which are:
- Code splitting;
- Image optimization and or booking an image server;
- Cache utilization;
- Asynchronous requests;
- Debounce in text fields;
- Review the query time of the bank; * Only moving the front is no miracle, if your problem is loading request the backend has to put his hand too
Thinking about the React components she leaves some tooltips:
React DevTools: To check what you have to update in virtual-DOM;
Highlight Updated Options: Checking unnecessary renders
It also recommends isolating frequent update regions, such as a timer, and whenever possible using PureComponet’s or React.Memo.
I will give you a quick look at each of these little questions answered by him and with some points of mine.
Why Monorepo? I am not an expert on Monorepo, in fact, I need to go deep, I am not very reputable with the theme, but João explains that they decided to adopt Monorepo for practicality and a few more things that I I prefer not to go deeper because of what I said at the beginning.
Why MongoDB? MongoDB was a decision because it is a NoSQL database, so they decided to adopt it. I have already worked with MongoDB on particular projects, and I love it, besides having a great learning curve is very simple for those who are starting to move and for those who are already moving.
Why GraphQL? Another technology that caught my attention during React Conf Brasil 2019 with TypeScript was GraphQL not only new projects are adopting but old projects are migrating, the most spoken phrase there was that “GraphQL is here to stay”, so needless to say nothing more. João pointed out that REST was an evolution of SOAP and GraphQL an evolution of REST that is here to stay.
Why Jest? Jest was one of the most mentioned test tools by most speakers, I already use Jest, and it just made me more sure I’m on the right track.
Why React and React Native? Really? do i really need to talk? But I’ve said so much … but, in short, the fact that you can reuse code from both to develop is something out of the ordinary, and it’s one of the thousands of advantages of having React and React Native in your stack
Why Styled-Components? One of the great loves of my life is this little guy there. I was even thinking of bringing a post of his own here, so much that I like it. I tell my colleagues that I can’t handle CSS anymore if I don’t use Styled-Components, and there it also made me sure that it is very high in the market, it is in the stack of big developers and big companies like João and Foton.
These palettes only made me sure that where I work at Zaal and what I have been studying and deepening is on the right track, we have not yet adhered to all tools on the list, but more than half are in use, and some with future plans.
Talk Slide: https://jgcmarins.github.io/the-golden-stack/#0
Pablo Dinella highlighted the important difference between using Enzyme and Testing Library.
If you don’t know Testing Library is a very lightweight solution for testing React components. It provides light utility functions on top of ReactDOM in a way that encourages best test practices. The idea of this library is to serve as a replacement for Enzyme.
I once heard a phrase that said, “For you to be a senior programmer, you must be in the habit of writing daily tests,” and this presentation just made me more sure of that.
Well, he points out that Enzyme can:
* browse the components tree; * make selections (CSS selectors, component name ...); * access props and state; * execute methods;
And it says the things that the testing library does NOT do:
* Shallow rendering shallow () * Static rendering render () * Component tree navigation * Get component instance * Access and set props * Access and set state
“These are all things the end user can’t do, so your test shouldn’t do either”
It goes deeper and makes the characteristic of each explicit:
- Based on component return
- Facilitates component tree navigation
- Simulates interactions
- Tests implementation
- Based on rendered DOM
- Has “humanized” selectors
- Interactions on DOM Nodes
- Forehead from thin user point of view
ReasonML gave what to say at React Conf Brasil 2019, I had never heard before, it was presented by Gabriel Rubens in a very humorous and very straightforward presentation.
For those who are like this down there like me and have never heard of ReasonML, I will try to explain quickly.
ReasonML is nothing more than the new programming language of … Facebook.
Gabriel made it very clear in the presentation that it is practically impossible to compile error code using ReasonML, I’ve seen it before in Delphi hehehehehe
Just kidding, so why was the talk so “controversial”?
So would it be time well spent studying this new language?
It has generated a debate, but just like everything else in life, everything has its pro and con side, so I leave below the Gabriel slide presentation link and a very good ReasonML article if you are interested in drawing your own conclusions.
Talk Slide: https://es2077-reactconf.netlify.com/0
Finally, it was also the talk that ended React Conf Brasil 2019, Preston So that came straight from New York ** (seriously, he arrived from the airport and went to talk) **, talked about Gatsby today and Gatsby in the future.
For those who do not know what Gatsby is, Gatsby is a very fast React based website building framework.
And for those who don’t know too, my blog is made in Gatsby.
One of the main points was when he announced that Gatsby is working to improve builds, because when you have a site with many pages, it takes a long time for everything to be “built”, they are aware of it, and are looking for this improvement for an upcoming release.
In addition, the Gatsby Preview which is still in beta was also announced.
Well, Coders, that’s it, I could talk a lot more, but I think the main one I brought here, I hope so. It was a unique experience, and I hope to be back next year to find out what’s coming.
I would like to thank my friend Elan for contributing and helping me to remember some points.
See you later!