Skip to content

2018 React Boston

Jump to bottom
Chad Koepf edited this page Oct 1, 2018 · 3 revisions

React Boston 2018

Chad Koepf

I don't want to break down all the information by talk because this conference had a lot of overlap. I'm going to go over the cool stuff I heard, and link to the videos when they post them.

Interesting tools

  • Reason (OCML language with ties to react)
  • Bucklescript brings reaason code together with react
  • Storybook & Zepplin (tools for getting style guides easier into the hands of developers)
  • Redux starter kit (node module that builds out the scaffolding for a redux application)
  • immer (node module that fixes immutable updates for redux)
  • react suspense (coming soon and very unstable, but changes async calls and makes things easier)
  • react spring (visualization tools with react)
  • pose (more cool visualization)
  • css houdini (new css features that are of course not handled by anything but the most modern browser)
  • write functional components (I need to look more into this, but it takes all the state information and declaration out of react components. I've never done it, but if it's a cleaner way to write, I'm down to try)
  • element.getBoundingClientRect() (returns the location of an element on a page)

Slides

Interesting thoughts

  • many of the presenters used ligature fonts in their IDE's. I had never seen, or paid attention to this, but it seemed to make the code more readable, however, it made it very confusing to follow along since I was unfamiliar
  • new version of redux is coming soon, redux 5. It's supposed to keep the current API very similar, so almost all codebases will work without changes. it's tagged next-995 and next-1000 on github if we wanna try it to see if it breaks anything before it goes live
  • a lot of talk and push toward graphql which I will describe below

Don't be afraid of whimsey

This was a talk I didn't think I'd pay much attention to, but I really learned a lot and had some good takeways. The main idea being it's cool to see a neat animation when demoing something, or the first time you use it. The example in the talk was an email being sent that animated into a folder up envelope that shot off when sent. That's cool and a neat affect but no one wants to see that after 2 or 3 times. The idea of a checkbox to remove animation was discussed, but why not speed up the animations over time, say, every 2 or 3 times the animation is to be shown until eventually it animates so fast that it's not noticeable and then remove the animation altogether.

Another interesting point from this same talk that is interesting to think about is the second half of his animation. When the envelop folded and animated away, it actually animated to the location on the page that is the link to the "outbox" of the email client. This is cool, but if you SAVE a draft, it would do a similar animation, but it would animate to the "saved drafts" link in the client. This is a way to use animations and eye catching things to actually train the user. Now if the user is looking for the draft they just prepared, they saw it animate to the drafts folder. This saves from making walkthrough tutorials with 46 steps that no one actually want to step through.

Humanizing Pull Requests

Another talk that stood out to me. The speaker discussed how people are very territorial about their code. No one wants to hear how bad their code works, or looks. When someone works long and hard to fix a problem, and it's not fixed, telling them it's still broken in a negative way can really be soul crushing. Some tips from this talk that I found interesting:

*Use emoji. It makes things more human, takes away the stale feeling of a normal response to a ticket *Don't think of things as "my code" and "your test procedures" but think of it as "our codebase". *Try talking in person preliminarily before the PR so that you can interact and explain things in a way that might be hard to explain over just text *Use gifs instead of static screenshots when possible. It should give more visual feedback and make it easier to replicate issues.

There were a ton of examples in her talk that I found very interesting.

Graphql

A big focus of the conference was on graphql. So much so that many presenters talked about it like the Boston graphql conference. Brief overview, graphql sits on top of your mongoDB, you make ONE endpoint to the backend. All relationships are defined in the graphql backend. Then on the front end you send to the back end a blank json object, and the backend returns that json object full. You request things you want, ignore things you don't, and graphql returns, in ONE trip to the backend, everything the front end will need.

There are even node modules out there that do this even better. One babelblade (slides: https://t.co/IEVKqY2qaa) allows you to write a front end piece that has all the data you will need, and then it writes the graphql query FOR YOU. If we were starting a new application from scratch, this would be a really solid option as it limits the amount of backend writing you need to write. Only one endpoint as opposed to hundreds, and the front end has the control of what they need without needing to ask the back end guys for ANOTHER endpoint.

Example code here: https://t.co/BRXhlhQa74 This example uses the github api to search for users. It's very fast and powerful and a good representation of the front end side of graphql.

ACES Learn to Code

Other Tutorials

Conferences

Training

Clone this wiki locally