I'm developing a React component library for a web site. For local development I use Storybook. I think bit can be a good tool (better than npm link) for exporting library components and import them into the web site repo. Now the problem is that I'm using global context for some components but bit components must be isolated and self-sufficient. I don't want to wrap all my tiny components that use global context only to render them on bit.dev!
I have been able to resolve the same problem with storybook using decorators. So, I define a component without wrapping it with a ContextProvider and then in the stories file I use a decorator that wraps my component with the ContextProvider.
Is there a way to wrap bit components with global context provider without wrapping the actual component that will be used in production web site where a single global context provider wrap the entire app? What about best practices about this kind of workflow?
Using global context when implementing reusable components is not recommended.
Not only when using Bit, but when another project consumes a component it needs to have the same exact context for the component to work. Making the component less reusable and attractive to consumers.
The fact that this is not comfortable for rendering examples on the playground in bit.dev is a side-effect for it.
What you can do is either decouple the state from the component and use the params to get state and actions directly, via APIs. Or you can encapsulate the state inside the component.
You can read more about it in Bit's best practices for building reusable components - https://docs.bit.dev/docs/best-practices#state-managers
and also here - https://github.com/Tallyb/reusable-components-styleguide#globals
Related
Is it possible to use both Functional and Class Components in a single React App?. I am building a website UI with React, back end has been build with NodeJS. The templates I am using was build with Class Components where they new Components I am introducing are Functional with Context API's. Can they work together or is it necessary I convert all the Class Components to Functions?.
Yes, you can use both in the same app. They are 100% compatible.
Each one can pass props to the other
They will be both compiled into plain javascript.
Quote from reactjs.org :
In React apps, whether a component is stateful or stateless is
considered an implementation detail of the component that may change
over time. You can use stateless components inside stateful
components, and vice versa.
Another quote from here :
"Crucially, Hooks work side-by-side with existing code so you can
adopt them gradually. There is no rush to migrate to Hooks. We
recommend avoiding any “big rewrites”, especially for existing,
complex class components. It takes a bit of a mindshift to start
“thinking in Hooks”. In our experience, it’s best to practice using
Hooks in new and non-critical components first, and ensure that
everybody on your team feels comfortable with them."
Context state can just be an observable and update components who subscribe like the observer pattern.
If you need the context state in a component just subscribe to a specific context.
Why do we need to render the context provider at the root of the app in order to use it somewhere else?
I ask since i see many libraries and apps use context now as the main way to share state between components but I don't understand the need to render the provider at the root of the app since each shared state (context) could be initialized outside of render functions
I made an npm package that does something similar in order to simplify the context/shared states of an app as an example of what i mean
https://www.npmjs.com/package/jstates
And a package for react bindings
https://www.npmjs.com/package/jstates-react
The reason is IMHO is recat tries to follow a paradigm where you don't have global state.
In general you want state to be as local as possible.
This allows better testing where you can feed mock state into the provider easily.
If you have a global object where everyone subscribe to it would be unclear where state is coming from.
With the context provider it very clear and state is encapsulated inside the component tree (no global objects).
Context API has to support multiple instances of the same context provider (e.g. while migrating part of the project to a new version of some library).
Even if libraries that use Context are most often used as singletons (for managing global state), when Thinking in React, authors need to support composable Components, not just global singletons. React API design also prefers Components over other patterns when feasible (e.g. <Suspense /> and <Provider />, but not life cycle hooks).
When designing support of multiple instances, some pattern for inversion of control is advisable for easier debugging (more constrains == less things that could go wrong).
Thus, explicit visibility in the React Components tree is preferred (notice that even life cycle methods and hooks are visible in the tree node details - but you only need to see those for a single node, not to identify "all children that have access to this context").
I have some Question in mind while switching to context API in react js .
What is the advantages of New context API in React js .
Can we use Redux along with context api ?
What are the overcome of context api on redux if any ?
so here is the answers to your questions.
With context react now have builtin support for state management so you don't need third party lib like redux or mobx.
Yes, you can but not required, however, you can use reducers with context to handle complex state management.
Less boilerplate code, especially with hooks and not dependency on third party lib and for small project context, makes it very simple and easy.
If you are looking for example then I created this repo to demo and check other branches to explore more ways of using context.
https://github.com/smkamranqadri/react-hooks-context-todo
We will be doing our first project using React.
It will not be a Single Page App, but a Multiple Page App.
What I'm trying to figure out at the moment is : what's the difference between a component and an app.
If I only use components, can I still use Redux to have some state management on the current page ? Or do I need an app for this ?
Thanks for the information you can bring !
THoma
There is no special object called "React App". React Components build an "React App" by coming together.
But React Components are formed like tree structure. That means each component have a parent component so you can create a React Component that named "App" and can put another components inside it.
You don't need redux for state management in React Components.
I hope the answers have helped.
Your app may contains a single component and still it will be a react App. If you are using multiple components in a page you can still use react-redux. Redux is basically a container for your states and let suppose you need some state from one component to be consumed in another, Redux provide you a mechanism to make the communication efficient and predictable.
You can also look at the React Context APIs as an alternate to Redux.
An app is simply a component that holds the root of the work you are trying to do. For example an App may have the navigation menu, testimonials, adverts, content, login avitar etc.
If you are making a single App per page (For example a testimonial) then you would still have a SPA. For example, adding testimonials, searching, editing.
You should only use Redux if you are using a SPA with lots of different parts with data in common. If you are making a one-app-per-page and there is no cross over in data then you can simply using Reacts State/Props to hold your data.
Redux is good, but it forces you into a complex path your should try to avoid. If you find yourself wanting data from different domains (customers address and a list of testimonials) then you should use Redux.
If this is a new applications (green) then I strongly recommend you build the whole thing within a SPA using React-Router to control components. you can use frameworks like Next.JS to ensure the site remains small in size (dynamically loading script only when required).
If Cycle uses virtual dom and so does React, then why can I not use React Components inside a Cycle.js app?
Would it be possible to use wrap existing React Components into Cycle.js components ?
This question relates to : Higher order FRP with React - why is it not happening?
Because React's support for Web Components is lacking. See https://github.com/facebook/react/issues/7901 and http://staltz.com/react-could-love-web-components.html
It is technically possible to build React support in Cycle.js, but then you may also start asking whether other frameworks like Ember or Angular or Aurelia should start doing the same out of the box. Then, the question could be expanded even further by asking Aurelia components to be supported in Ember. So building support for "Foo" components in "Bar" framework is counter-productive. Web Components are the sane way to handle this.
Cycle.js is generic enough to be used along other frameworks/libraries. In fact there's redux-cycle-middleware which allows you to use React/Redux along with Cycle.js. With this middleware you wouldn't be using Cycle to handle DOM side-effects; instead you'd use React. Then when you need to handle other side-effects (HTTP, WebSockets, anything that isn't DOM...) you can use Cycle.js.