In a previous post, I told you that we’re all noobs and that we have to continue learning no matter what. Well, I lied! It’s true that you have to keep learning, but you’re not a noob, no one is and here is why.
You’re not a noob, you learned how to draw a square using Photoshop, you can start a business to design and sell business cards.
You’re not a noob, you learned how to write some HTML/CSS, create a website for your parents’ business.
You’re not a noob, you learned how to write a MySQL query, thus, create a private social website for your class to share tutorials, videos, lessons and other resources.
You’re not a noob, you learned how to install WordPress, start blogging to teach others how to do the same.
You’re not a noob, you installed a custom theme, create a web agency to setup WordPress for clients.
You’re not a noob, you have several comments on your blog posts and people are sharing your interests, talk to them, gather, create a community.
You’re not a noob, you wrote your first VueJS component, Draft a blog post about it and show us how to do so.
You’re not a noob, you learned Git and found a typo on React’s documentation, submit a PR, Dan Abramov will appreciate.
You’re not a noob, you abstracted your Data Layer for your application in a library, share it with the world on GitHub and tell us why it’s awesome.
You’re not a noob, you learned a new fancy language called Reason, propose a talk for your local meetup and share with friends.
You’re not a noob, you know JS and James Long just released Prettier, engage with him in issues and PRs and see how you could contribute.
You’re not a noob, you gave a talk on your city’s local JS Developer Group, propose it for ReactEurope, who knows, others might be interested.
You’re not a noob, you’re feeling like you’re, you’re feeling the imposter syndrome, deal with it and move forward. Whenever you feel like a noob, don’t let this feeling stop you from doing what you want to do. Try harder, accept criticism, learn and move forward.
When we hear about GraphQL, it’s often mentioned as the new way to retrieve data from the server. The silver bullet that will replace REST APIs. This is true, GraphQL can do an amazing job to run the new generation of server APIs but this is not the whole picture.
From the homepage of the official website, GraphQL is described as “A query language for your API” where you:
First, describe your data
Then, ask for what you want
Finally, obtain predictable results
We quickly make the assumption that it allows us to query server APIs using HTTP requests but if we take a deeper look at the official JavaScript implementation, we understand that this is not totally true, GraphQL is a query language for any Data Provider whether it’s local or remote.
Many Tools have been developed to ease the use of GraphQL server-side: From Relay, Apollo Data Tools, express-graphql etc… but few people focused on using it on the client. While you’ll probably get the most of it, if it’s used server-side, using GraphQL on the client can be valuable as well and often, using GraphQL on the server requires a big investment where you probably have to rewrite your entire application to make the transition.
A typical React/Redux application
In the React Ecosystem, a large number of applications are using Redux to store their data in a global state tree. How can we use GraphQL to improve the architecture of such applications without rewriting our application from scratch?
So first, let’s try to take a look at a typical React/Redux Application (A Todo Application of course). We’ll probably have:
A reducer that “stores” the data in the global state: todos reducer,
An action creator used to retrieve todos from the server: fetchTodos
In most cases, This action creator will rely on redux-thunk to trigger a network request and dispatch the action once the results retrieved.
A selector getTodos responsible of retrieving the todos from the global state
And to link all of these items together, we would use react-redux to bring our data and action creators to our component. A complete TodoList React Component could look like that:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Let’s take a deeper look at this component. It has three responsibilities:
It triggers an action creator to fetch Data
It uses a selector to retrieve Data from the redux tree
And it renders the Data
React’s main purpose is providing a declarative API, to express how your data get transformed into DOM elements, but in our example above, the fetching and data retrieval is imperative. This means it’s the responsibility of the persons who write the component to trigger the data fetching requests and eventually handles data refreshing. And in this area, Relay has been doing a great job to transform these imperative calls into a declarative API. What if we could provide a declarative API (similar to Relay) without the need of rewriting our APIs to use GraphQL? and without even using Relay?
We want our component to be written like this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
If we need more data such as the authenticated user, our query could be:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Basically, we use a Higher Order Component called query to declare that our component needs a list of todos, and for each todo, we want its id, text, and done attributes. We don’t mind how this data is fetched from the server or retrieved from the redux store, we just declare what data the component needs and it will be made available as a prop.
How is this possible?
Ok! this sounds awesome right! but isn’t this too difficult to achieve, how do we match each part of this query to its corresponding actions / selectors?
We need a tree resolution algorithm where we match each node of the tree to a function that fetches and retrieves this data. And you know!! this is exactly the purpose of GraphQL. A way to match a query to resolvers.
Ok! Let’s setup GraphQL to resolve the query above:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
The idea here is for every node of our query, we write:
1- A schema: A good side effect of using GraphQL is the schema which will be used to validate our data. This ensures a valid data is provided to all your React Components.
2- A resolver: A function with the following shape:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Make our GraphQL resolvers available for the query HoC
Now that our GraphQL setup is ready, we can make it available on the React context, that way the query HoC can use it to provide data to the wrapped components. This is the exact same technique used by react-redux to make the store available for connected components.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Now, you are ready to go! wrap your components with query HoC.
Is this worth it?
If you’re working on a small application with dozen of actions and selectors, probably not. Just stick with the imperative fetching, but If your application is big enough, I would say, this is certainly worth a try.
Good benefits
I already mentioned the fact that using GraphQL allows you to validate your data, you are certain that the data provided to your components would always be valid against the defined schema.
Another good side effect is the possibility to use GraphiQL. If you’re not familiar with it yet, it’s a web interface which allows you to test your GraphQL queries before using them in your components. Also, it allows you to navigate through your data which increases data discoverability a lot. You won’t lose your time looking or rewriting existing redux selectors, if the data is already available, you’ll just find it in GraphiQL.
Library
You can find the query HoC and the GraphProvider in this library, but it’s easy enough to write on your own if you prefer to.
Who is using this approach already?
Me:). I don’t know if anyone else is but we’re considering using it for Calypso, the new WordPress.com front-end. Here is the PR
Time to get your hands dirty! and let me know if you have any thoughts or concerns on this 🙂
Now, that I'm back in Algeria. Let's try to build a solid developers community together. A first small step is trying to gather all these hidden developers. For that purpose, I put together an Awesome Algeria repository on GitHub.
J’ai rejoint Automattic il y’a quelques semaines, et à travers ce post, je vous fais découvrir une journée de travail classique (ou presque) pour un développeur Lambda chez A8C, en sachant que c’est une société assez atypique puisque tous les employés y travaillent à distance. En espérant vous convaincre de nous rejoindre !!
I have to admit, It took me some time to figure out in which use cases ES6 generators could be really useful (I’m not the only one I think, am I ?). When we talk about ES6 (or ES2015 as you like), generators are not the first feature we think about, we often see them as an easy way to create custom iterators, but in reality they are much more than that, they are maybe one of the most interesting features added in ES6. (more…)
There’s this expression I say each time I stumble on something (some technology) that’s going to change my habits in development …. Oh, ça déchire sa mère 😛 a not so conventional french alternative to wow that’s great !!!.
And you know what, It just happened again. I discovered redux-saga, And I’m like: “Wow this is great, that’s exactly what I was looking for”
Unidirectional data flow (or sometimes referred to as reactive programming or functional programming) is often seen as this new trend in frontend applications development brought by React and Flux (or by ReactiveX from Netflix). So many developers think using one of these libraries or frameworks is necessary to start with this pattern. This, of course, is not true. I can use React and don’t have an unidirectional data flow at all, and the opposite, I can use stacks not designed with functional reactive programming in mind and still have an unidirectional data flow.
In the last three years, frontend development has evolved very quickly. With all this stuff out there (react, angular.js, aurelia, redux, flux, Angular2, Rx.js, falcor…), it became really hard for developers and companies to make choices about the stack to use for their applications. (more…)
Hymne à l’autocritique et à l’amélioration continue
Cet article est une ancienne partipation au DZBlogDay 2013. Le DZBlogDay, événement annuel pendant lequel les blogueurs algériens abordent le même sujet le même jour, le thème de cette édition était le “web algérien”. Comme vous le savez, on ne peut parler de web sans parler de développeur web, et donc pour avoir un “web” de qualité, il faut avoir de bons développeurs web d’où l’idée de mon article.