React Query En Tant Que Gestionnaire D'état

React Query est apprécié par beaucoup pour simplifier considérablement la récupération de données dans les applications React. Cela pourrait donc être un peu surprenant si je vous dis que React Query n'est en fait PAS une bibliothèque de récupération de données.

Il ne récupère aucune donnée pour vous, et seul un très petit ensemble de fonctionnalités est directement lié au réseau (comme OnlineManager , refetchOnReconnect ou retrying offline mutation ). Cela devient également évident lorsque vous écrivez votre premier queryFn , et vous devez utiliser quelque chose pour obtenir les données, comme fetch , axios , ky ou même graphql-request .

Donc, si React Query n'est pas une bibliothèque de récupération de données, qu'est-ce que c'est ?

Un gestionnaire d'état asynchrone

React Query est un gestionnaire d'état asynchrone. Il peut gérer n'importe quelle forme d'état asynchrone - il est heureux tant qu'il obtient une promesse. Oui, la plupart du temps, nous produisons des promesses via la récupération de données, c'est donc là que ça brille. Mais il fait plus que simplement gérer le chargement et les états d'erreur pour vous. Il s'agit d'un véritable "gestionnaire d'état global". Le QueryKey identifie de manière unique votre requête, donc tant que vous appelez la requête avec la même clé à deux endroits différents, ils obtiendront les mêmes données. Cela peut être mieux résumé avec un crochet personnalisé afin que nous n'ayons pas à accéder deux fois à la fonction de récupération de données réelle :

gestionnaire d'état asynchrone

export const useTodos = () => useQuery(['todos'], fetchTodos)

function ComponentOne() {
  const { data } = useTodos()
}

function ComponentTwo() {
  // ✅ will get exactly the same data as ComponentOne
  const { data } = useTodos()
}

const queryClient = new QueryClient()

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <ComponentOne />
      <ComponentTwo />
    </QueryClientProvider>
  )
}

Ces composants peuvent se trouver n'importe où dans votre arborescence de composants. Tant qu'ils sont sous le même QueryClientProvider , ils obtiendront les mêmes données. React Query dédupliquera également les requêtes qui se produiraient en même temps, donc dans le scénario ci-dessus, même si deux composants demandent les mêmes données, il n'y aura qu'une seule requête réseau.

Un outil de synchronisation de données

Étant donné que React Query gère l'état asynchrone (ou, en termes de récupération de données : l'état du serveur), il suppose que l'application frontale ne "possède" pas les données. Et c'est tout à fait vrai. Si nous affichons des données sur l'écran que nous récupérons à partir d'une API, nous n'affichons qu'un "instantané" de ces données - la version de leur apparence lorsque nous les avons récupérées. Alors la question que nous devons nous poser est :

Ces données sont-elles toujours exactes une fois que nous les avons récupérées ?

La réponse dépend totalement de notre domaine de problème. Si nous récupérons une publication Twitter avec tous ses goûts et commentaires, elle est probablement obsolète (périmée) assez rapidement. Si nous récupérons des taux de change mis à jour quotidiennement, eh bien, nos données seront assez précises pendant un certain temps, même sans nouvelle récupération.

React Query fournit les moyens de synchroniser notre vue avec le véritable propriétaire des données - le backend. Et ce faisant, il se trompe du côté de la mise à jour souvent plutôt que de ne pas mettre à jour assez souvent.

Avant la requête de réaction

Deux approches de récupération de données étaient assez courantes avant que des bibliothèques comme React Query ne viennent à la rescousse :

récupérer une fois, distribuer globalement, mettre à jour rarement
C'est à peu près ce que j'ai moi-même beaucoup fait avec redux. Quelque part, j'envoie une action qui lance la récupération des données, généralement au montage de l'application. Après avoir obtenu les données, nous les plaçons dans un gestionnaire d'état global afin que nous puissions y accéder partout dans notre application. Après tout, de nombreux composants doivent accéder à notre liste de tâches. Récupérons-nous ces données ? Non, nous l'avons "téléchargé", donc nous l'avons déjà, pourquoi devrions-nous ? Peut-être que si nous envoyons une requête POST au backend, il aura la gentillesse de nous renvoyer le "dernier" état. Si vous voulez quelque chose de plus précis, vous pouvez toujours recharger la fenêtre de votre navigateur...

récupérer sur chaque montage, le garder local
Parfois, nous pourrions aussi penser que mettre les données dans un état global est "trop". Nous n'en avons besoin que dans ce dialogue modal, alors pourquoi ne pas le récupérer juste à temps lorsque le dialogue s'ouvre. Vous connaissez l'exercice : useEffect , tableau de dépendances vide (lancez-lui un eslint-disable s'il crie), setLoading(true) et ainsi de suite ... Bien sûr, nous affichons maintenant un spinner de chargement à chaque ouverture de la boîte de dialogue jusqu'à ce que nous ayons les données. Que pouvons-nous faire d'autre, l'état local est parti...

Ces deux approches sont assez sous-optimales. Le premier ne met pas à jour notre cache local assez souvent, tandis que le second récupère potentiellement trop souvent, et a également un ux discutable car les données ne sont pas là lorsque nous récupérons pour la deuxième fois.

Alors, comment React Query aborde-t-il ces problèmes ?

Obsolète pendant la revalidation

Vous avez peut-être déjà entendu cela, c'est le mécanisme de mise en cache utilisé par React Query. Ce n'est pas nouveau - vous pouvez en savoir plus sur les extensions HTTP Cache-Control pour le contenu obsolète ici . En résumé, cela signifie que React Query mettra les données en cache pour vous et vous les donnera quand vous en aurez besoin, même si ces données ne sont plus à jour (périmées). Le principe est que des données obsolètes valent mieux que pas de données, car pas de données signifie généralement un spinner de chargement, et cela sera perçu comme "lent" par les utilisateurs. En même temps, il essaiera d'effectuer une nouvelle récupération en arrière-plan pour revalider ces données.

Récupérations intelligentes

L'invalidation du cache est assez difficile, alors quand décidez-vous qu'il est temps de redemander au backend de nouvelles données ? Nous ne pouvons certainement pas faire cela à chaque fois qu'un composant qui appelle useQuery se restitue. Ce serait incroyablement cher, même selon les normes modernes.

React Query est donc intelligent et choisit des points stratégiques pour déclencher une nouvelle récupération. Des points qui semblent être un bon indicateur pour dire : "Oui, ce serait le bon moment pour aller chercher des données". Ceux-ci sont:

refetchOnMount
Chaque fois qu'un nouveau composant qui appelle useQuery se monte, React Query effectuera une revalidation.

refetchOnWindowFocus
Chaque fois que vous concentrez l'onglet du navigateur, il y aura une refetch. C'est mon moment préféré pour faire une revalidation, mais c'est souvent mal compris. Pendant le développement, nous changeons très souvent d'onglets de navigateur, nous pouvons donc percevoir cela comme "trop". Cependant, en production, cela indique très probablement qu'un utilisateur qui a laissé notre application ouverte dans un onglet revient maintenant après avoir vérifié ses e-mails ou lu Twitter. Leur montrer les dernières mises à jour est parfaitement logique dans cette situation.

refetchOnReconnect
Si vous perdez votre connexion réseau et que vous la retrouvez, c'est aussi un bon indicateur pour revalider ce que vous voyez à l'écran.

Enfin, si vous, en tant que développeur de votre application, connaissez un bon moment, vous pouvez invoquer une invalidation manuelle via queryClient.invalidateQueries . Ceci est très pratique après avoir effectué une mutation.

Laisser React Query faire sa magie

J'adore ces paramètres par défaut , mais comme je l'ai déjà dit, ils visent à maintenir les choses à jour, et non à minimiser le nombre de requêtes réseau. C'est principalement parce que staleTime est par défaut à zéro , ce qui signifie que chaque fois que vous montez par exemple une nouvelle instance de composant, vous obtiendrez une nouvelle récupération en arrière-plan. Si vous faites cela souvent, en particulier avec des montages en succession courte qui ne sont pas dans le même cycle de rendu, vous pourriez voir beaucoup de récupérations dans l'onglet réseau. C'est parce que React Query ne peut pas dédupliquer dans de telles situations :

monte-en-court-succession

function ComponentOne() {
  const { data } = useTodos()

  if (data) {
    // ⚠️ mounts conditionally, only after we already have data
    return <ComponentTwo />
  }
  return <Loading />
}

function ComponentTwo() {
  // ⚠️ will thus trigger a second network request
  const { data } = useTodos()
}

const queryClient = new QueryClient()

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <ComponentOne />
    </QueryClientProvider>
  )
}

Que se passe-t-il ici, je viens de récupérer mes données il y a 2 secondes, pourquoi y a-t-il une autre requête réseau en cours ? C'est insensé!

— Réaction légitime lors de la première utilisation de React Query

À ce stade, il peut sembler être une bonne idée de transmettre les données via des accessoires, ou de les mettre dans React Context pour éviter le forage d'accessoires, ou simplement de désactiver les indicateurs refetchOnMount / refetchOnWindowFocus car toute cette récupération est tout simplement trop !

Généralement, il n'y a rien de mal à transmettre des données en tant qu'accessoires. C'est la chose la plus explicite que vous puissiez faire et cela fonctionnerait bien dans l'exemple ci-dessus. Mais que se passe-t-il si nous modifions un peu l'exemple vers une situation plus réelle :

second composant paresseux

function ComponentOne() {
  const { data } = useTodos()
  const [showMore, toggleShowMore] = React.useReducer(
    (value) => !value,
    false
  )

  // yes, I leave out error handling, this is "just" an example
  if (!data) {
    return <Loading />
  }

  return (
    <div>
      Todo count: {data.length}
      <button onClick={toggleShowMore}>Show More</button>
      // ✅ show ComponentTwo after the button has been clicked
      {showMore ? <ComponentTwo /> : null}
    </div>
  )
}

Dans cet exemple, notre deuxième composant (qui dépend également des données de la tâche) ne se montera qu'après que l'utilisateur aura cliqué sur un bouton. Imaginez maintenant que notre utilisateur clique sur ce bouton après quelques minutes. Une récupération en arrière-plan ne serait-elle pas agréable dans cette situation, afin que nous puissions voir les valeurs à jour de notre liste de tâches ?

Cela ne serait pas possible si vous choisissiez l'une des approches susmentionnées qui contournent essentiellement ce que React Query veut faire.

Alors, comment pouvons-nous avoir notre gâteau et le manger aussi ?

Personnaliser staleTime

Peut-être avez-vous déjà deviné la direction dans laquelle je veux aller : la solution serait de définir staleTime sur une valeur avec laquelle vous êtes à l'aise pour votre cas d'utilisation spécifique. L'essentiel à savoir est :

Tant que les données sont fraîches, elles proviendront toujours du cache uniquement. Vous ne verrez pas de demande réseau de nouvelles données, quelle que soit la fréquence à laquelle vous souhaitez les récupérer.

Il n'y a pas non plus de valeur "correcte" pour staleTime . Dans de nombreuses situations, les valeurs par défaut fonctionnent très bien. Personnellement, j'aime le régler sur un minimum de 20 secondes pour dédupliquer les requêtes dans ce laps de temps, mais cela dépend entièrement de vous.

Bonus : utilisation de setQueryDefaults

Depuis la v3, React Query prend en charge un excellent moyen de définir des valeurs par défaut par clé de requête via QueryClient.setQueryDefaults . Donc, si vous suivez les modèles que j'ai décrits dans # 8 : Effective React Query Keys , vous pouvez définir des valeurs par défaut pour la granularité souhaitée, car le passage des clés de requête à setQueryDefaults suit la correspondance partielle standard que, par exemple, les filtres de requête ont également :

setQueryDefaults

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      // ✅ globally default to 20 seconds
      staleTime: 1000 * 20,
    },
  },
})

// 🚀 everything todo-related will have a 1 minute staleTime
queryClient.setQueryDefaults(todoKeys.all, { staleTime: 1000 * 60 })

Une note sur la séparation des préoccupations

C'est une préoccupation apparemment légitime que l'ajout de crochets comme useQuery aux composants de toutes les couches de votre application mélange les responsabilités de ce qu'un composant doit faire. À l' époque , le modèle de composant "intelligent contre muet", "conteneur contre présentation" était omniprésent. Il promettait une séparation, un découplage, une réutilisabilité et une facilité de test clairs, car les composants de présentation n'obtiendraient que des accessoires. Cela a également conduit à de nombreux perçages d'accessoires, à des passe-partout, à des modèles difficiles à taper statiquement (👋 composants d'ordre supérieur) et à des fractionnements de composants arbitraires.

Cela a beaucoup changé lorsque les crochets sont apparus. Vous pouvez maintenant useContext , useQuery ou useSelector (si vous utilisez redux) partout, et ainsi injecter des dépendances dans votre composant. Vous pouvez affirmer que cela rend votre composant plus couplé. Vous pouvez également dire qu'il est maintenant plus indépendant car vous pouvez le déplacer librement dans votre application, et il fonctionnera tout seul.

Je peux totalement recommander de regarder Hooks, HOCS et Tradeoffs (⚡️) / React Boston 2019 par le responsable de redux Mark Erikson .

Bref, tout est compromis. Il n'y a pas de repas gratuit. Ce qui peut fonctionner dans une situation peut ne pas fonctionner dans d'autres. Un composant Button réutilisable doit -il récupérer des données ? Probablement pas. Est-il judicieux de diviser votre tableau de bord en un DashboardView et un DashboardContainer qui transmettent les données ? Aussi, probablement pas. C'est donc à nous de connaître les compromis et d'appliquer le bon outil pour le bon travail.

Plats à emporter

React Query est idéal pour gérer l'état asynchrone globalement dans votre application, si vous le permettez. Ne désactivez les indicateurs de récupération que si vous savez que cela a du sens pour votre cas d'utilisation et résistez à l'envie de synchroniser les données du serveur avec un autre gestionnaire d'état. Habituellement, la personnalisation de staleTime est tout ce dont vous avez besoin pour obtenir un excellent ux tout en contrôlant la fréquence des mises à jour en arrière-plan.

C'est tout pour aujourd'hui. N'hésitez pas à me contacter si vous avez des questions, ou laissez simplement un commentaire ci-dessous. ⬇️

Source : https://tkdodo.eu/blog/react-query-as-a-state-manager

#react 

What is GEEK

Buddha Community

How native is React Native? | React Native vs Native App Development

If you are undertaking a mobile app development for your start-up or enterprise, you are likely wondering whether to use React Native. As a popular development framework, React Native helps you to develop near-native mobile apps. However, you are probably also wondering how close you can get to a native app by using React Native. How native is React Native?

In the article, we discuss the similarities between native mobile development and development using React Native. We also touch upon where they differ and how to bridge the gaps. Read on.

A brief introduction to React Native

Let’s briefly set the context first. We will briefly touch upon what React Native is and how it differs from earlier hybrid frameworks.

React Native is a popular JavaScript framework that Facebook has created. You can use this open-source framework to code natively rendering Android and iOS mobile apps. You can use it to develop web apps too.

Facebook has developed React Native based on React, its JavaScript library. The first release of React Native came in March 2015. At the time of writing this article, the latest stable release of React Native is 0.62.0, and it was released in March 2020.

Although relatively new, React Native has acquired a high degree of popularity. The “Stack Overflow Developer Survey 2019” report identifies it as the 8th most loved framework. Facebook, Walmart, and Bloomberg are some of the top companies that use React Native.

The popularity of React Native comes from its advantages. Some of its advantages are as follows:

• Performance: It delivers optimal performance.
• Cross-platform development: You can develop both Android and iOS apps with it. The reuse of code expedites development and reduces costs.
• UI design: React Native enables you to design simple and responsive UI for your mobile app.
• 3rd party plugins: This framework supports 3rd party plugins.
• Developer community: A vibrant community of developers support React Native.

Why React Native is fundamentally different from earlier hybrid frameworks

Are you wondering whether React Native is just another of those hybrid frameworks like Ionic or Cordova? It’s not! React Native is fundamentally different from these earlier hybrid frameworks.

React Native is very close to native. Consider the following aspects as described on the React Native website:

• Access to many native platforms features: The primitives of React Native render to native platform UI. This means that your React Native app will use many native platform APIs as native apps would do.
• Near-native user experience: React Native provides several native components, and these are platform agnostic.
• The ease of accessing native APIs: React Native uses a declarative UI paradigm. This enables React Native to interact easily with native platform APIs since React Native wraps existing native code.

Due to these factors, React Native offers many more advantages compared to those earlier hybrid frameworks. We now review them.

#android app #frontend #ios app #mobile app development #benefits of react native #is react native good for mobile app development #native vs #pros and cons of react native #react mobile development #react native development #react native experience #react native framework #react native ios vs android #react native pros and cons #react native vs android #react native vs native #react native vs native performance #react vs native #why react native #why use react native

React Query Tutorial | React Query For Beginners

Hey everyone! Today’s video is a short tutorial for React Query, I’ve been using it for a few months now and it’s been great! Would definitely recommend checking it out.

Useful Links:
GitHub: https://github.com/redhwannacef/youtube/tree/master/react-query

#react query tutorial #react #query #react query

React Query Mutations Tutorial

Hey everyone! In this week’s video, we are taking another look at React Query, specifically how to handle mutations. Hope you enjoy it!

Useful Links:
GitHub: https://github.com/redhwannacef/youtube/tree/master/react-query

#query #react #react query #react query tutorial

How to Select and Hire the Best React JS and React Native Developers?

Since March 2020 reached 556 million monthly downloads have increased, It shows that React JS has been steadily growing. React.js also provides a desirable amount of pliancy and efficiency for developing innovative solutions with interactive user interfaces. It’s no surprise that an increasing number of businesses are adopting this technology. How do you select and recruit React.js developers who will propel your project forward? How much does a React developer make? We’ll bring you here all the details you need.

What is React.js?

Facebook built and maintains React.js, an open-source JavaScript library for designing development tools. React.js is used to create single-page applications (SPAs) that can be used in conjunction with React Native to develop native cross-platform apps.

React vs React Native

• React Native is a platform that uses a collection of mobile-specific components provided by the React kit, while React.js is a JavaScript-based library.
• React.js and React Native have similar syntax and workflows, but their implementation is quite different.
• React Native is designed to create native mobile apps that are distinct from those created in Objective-C or Java. React, on the other hand, can be used to develop web apps, hybrid and mobile & desktop applications.
• React Native, in essence, takes the same conceptual UI cornerstones as standard iOS and Android apps and assembles them using React.js syntax to create a rich mobile experience.

What is the Average React Developer Salary?

In the United States, the average React developer salary is $94,205 a year, or $30-$48 per hour, This is one of the highest among JavaScript developers. The starting salary for junior React.js developers is $60,510 per year, rising to $112,480 for senior roles.

* React.js Developer Salary by Country

• United States- $120,000
• Canada - $110,000
• United Kingdom - $71,820
• The Netherlands $49,095
• Spain - $35,423.00
• France - $44,284
• Ukraine - $28,990
• India - $9,843
• Sweden - $55,173
• Singapore - $43,801

In context of software developer wage rates, the United States continues to lead. In high-tech cities like San Francisco and New York, average React developer salaries will hit $98K and $114per year, overall.

However, the need for React.js and React Native developer is outpacing local labour markets. As a result, many businesses have difficulty locating and recruiting them locally.

It’s no surprise that for US and European companies looking for professional and budget engineers, offshore regions like India are becoming especially interesting. This area has a large number of app development companies, a good rate with quality, and a good pool of React.js front-end developers.

As per Linkedin, the country’s IT industry employs over a million React specialists. Furthermore, for the same or less money than hiring a React.js programmer locally, you may recruit someone with much expertise and a broader technical stack.

How to Hire React.js Developers?

• Conduct thorough candidate research, including portfolios and areas of expertise.
• Before you sit down with your interviewing panel, do some homework.
• Examine the final outcome and hire the ideal candidate.

Why is React.js Popular?

React is a very strong framework. React.js makes use of a powerful synchronization method known as Virtual DOM, which compares the current page architecture to the expected page architecture and updates the appropriate components as long as the user input.

React is scalable. it utilises a single language, For server-client side, and mobile platform.

React is steady.React.js is completely adaptable, which means it seldom, if ever, updates the user interface. This enables legacy projects to be updated to the most new edition of React.js without having to change the codebase or make a few small changes.

React is adaptable. It can be conveniently paired with various state administrators (e.g., Redux, Flux, Alt or Reflux) and can be used to implement a number of architectural patterns.

Is there a market for React.js programmers?
The need for React.js developers is rising at an unparalleled rate. React.js is currently used by over one million websites around the world. React is used by Fortune 400+ businesses and popular companies such as Facebook, Twitter, Glassdoor and Cloudflare.

Final thoughts:

As you’ve seen, locating and Hire React js Developer and Hire React Native developer is a difficult challenge. You will have less challenges selecting the correct fit for your projects if you identify growing offshore locations (e.g. India) and take into consideration the details above.

If you want to make this process easier, You can visit our website for more, or else to write a email, we’ll help you to finding top rated React.js and React Native developers easier and with strives to create this operation

#hire-react-js-developer #hire-react-native-developer #react #react-native #react-js #hire-react-js-programmer

React Starter Kit: Build Web Apps with React, Relay and GraphQL.

React Starter Kit — "isomorphic" web app boilerplate   

React Starter Kit is an opinionated boilerplate for web development built on top of Node.js, Express, GraphQL and React, containing modern web development tools such as Webpack, Babel and Browsersync. Helping you to stay productive following the best practices. A solid starting point for both professionals and newcomers to the industry.

See getting started guide, demo, docs, roadmap  |  Join #react-starter-kit chat room on Gitter  |  Visit our sponsors:

 

Hiring

Getting Started

• Follow the getting started guide to download and run the project (Node.js >= 8.16.2)
• Check the code recipes used in this boilerplate, or share yours

Customization

The master branch of React Starter Kit doesn't include a Flux implementation or any other advanced integrations. Nevertheless, we have some integrations available to you in feature branches that you can use either as a reference or merge into your project:

• feature/redux (PR) — isomorphic Redux by Pavel Lang (see how to integrate Redux) (based on master)
• feature/apollo (PR) — isomorphic Apollo Client by Pavel Lang (see Tracking PR #1147) (based on feature/redux)
• feature/react-intl (PR) — isomorphic Redux and React Intl by Pavel Lang (see how to integrate React Intl) (based on feature/apollo)
• feature/apollo-pure (PR) — Apollo devtools and TypeScript integration by piglovesyou (based on master)

You can see status of most reasonable merge combination as PRs labeled as TRACKING

If you think that any of these features should be on master, or vice versa, some features should removed from the master branch, please let us know. We love your feedback!

Comparison

	React Starter Kit	React Static Boilerplate	ASP.NET Core Starter Kit
App type	Isomorphic (universal)	Single-page application	Single-page application
Frontend
Language	JavaScript (ES2015+, JSX)	JavaScript (ES2015+, JSX)	JavaScript (ES2015+, JSX)
Libraries	React, History, Universal Router	React, History, Redux	React, History, Redux
Routes	Imperative (functional)	Declarative	Declarative, cross-stack
Backend
Language	JavaScript (ES2015+, JSX)	n/a	C#, F#
Libraries	Node.js, Express, Sequelize, GraphQL	n/a	ASP.NET Core, EF Core, ASP.NET Identity
SSR	Yes	n/a	n/a
Data API	GraphQL	n/a	Web API

Backers

♥ React Starter Kit? Help us keep it alive by donating funds to cover project expenses via OpenCollective or Bountysource!

 

How to Contribute

Anyone and everyone is welcome to contribute to this project. The best way to start is by checking our open issues, submit a new issue or feature request, participate in discussions, upvote or downvote the issues you like or dislike, send pull requests.

Learn More

• Getting Started with React.js
• Getting Started with GraphQL and Relay
• React.js Questions on StackOverflow
• React.js Discussion Board
• Flux Architecture for Building User Interfaces
• Enzyme — JavaScript Testing utilities for React
• Flow — A static type checker for JavaScript
• The Future of React
• Learn ES6, ES6 Features

Related Projects

• GraphQL Starter Kit — Boilerplate for building data APIs with Node.js, JavaScript (via Babel) and GraphQL
• Membership Database — SQL schema boilerplate for user accounts, profiles, roles, and auth claims
• Babel Starter Kit — Boilerplate for authoring JavaScript/React.js libraries

Support

• #react-starter-kit on Stack Overflow — Questions and answers
• #react-starter-kit on Gitter — Watch announcements, share ideas and feedback
• GitHub issues, or Scrum board — File issues, send feature requests
• appear.in/react — Open hours! Exchange ideas and experiences (React, GraphQL, startups and pet projects)
• @koistya on Codementor, or Skype — Private consulting

License

Copyright © 2014-present Kriasoft, LLC. This source code is licensed under the MIT license found in the LICENSE.txt file. The documentation to the project is licensed under the CC BY-SA 4.0 license.

---

Author: kriasoft
Source Code: https://github.com/kriasoft/react-starter-kit
License: MIT License

#graphql #react