Stack: Meteor, React, Redux, React Router
Question: Where (i.e. in which file) do I instantiate Globalize? I am no expert on Globalize, but it feels like this is a somewhat global variable. So where does it go?
More generally speaking I am a bit confused as to where to put global variables in react/meteor applications. I get the whole component idea. And I write a component within its module, I import all the stuff I need and I export the component. Easy enough. However, where does the more general stuff go? Is there anything I could read up on?
Cheers
Related
I'm looking at the video https://youtu.be/uirRaVjRsf4. Apologies, there is no code for this, so I just captured the screen.
What I don't understand is when is the class Counter instantiated ? Usually in a program, I need to create the instance by calling Counter(xxxx). But in this react program, I cannot find the code to instantiate the object.
Thanks.
Class not a necessary instance when rendering component, but it is a short answer, but in some cases react engine preload class component in virtual DOM implementations and use shallow access to them. Because of this pattern, things like class stateful are not recommended these days because this keyword has been bound for virtual DOM and some unexpected behavior came from.
It would help if you read about component lifecycle to figure out how this "magic" works
I'm not really facing an issue, it's more like I'm wondering what is the best way I should use mobx with react. So here's my situation:
I'am fairly new to mobx but I've got years of experience using react (mostly with redux).
My new project is using mobx-state-tree alongside with mobx-react-lite in order to connect my components with the function observer wrapping the component. I've set up a root store with multiples stores in it.
I'm really enthusiastic about it for now but I would like some recommendations:
Should I use the containers logic which is pretty common with redux, which means I should only connect a "container" component who will handle the connection with my stores and spread it to its children ? Or should I connect directly with an observer as many components which needs to be provided with data from a store ?
Is the second option more optimized, technically speaking ? Is it still a good idea according to React philosophy ? What's YOUR opinion on this subject ?
Any answer would be really appreciated
Technically, you don't need container/presentation concept. You can use context, or localStore, or globalStore but it doesn't mean container/presentation not useful sometimes.
Mobx patches shouldComponentUpdate lifecycle, and basically optimizes components rendering for you.
mobx-react mentioned in their docs that the more components connected with observer, the better.
It's very common pattern to see shouldComponentUpdate with a bulky checks to avoid unnecessary renders. This isn't needed with MobX at all.
My opinion is that patterns change on monthly basis, so learning the general concepts can ease your transition from global store, local store, context, hooks and other api changes.
React component patterns also change overtime.
Use what you need and understand right now. If it won't matter in 5 years, don't spend more than 5 minutes to think about it. You can always do a fun refactor.
Further reading:
https://mobx.js.org/README.html
https://mobx-react.js.org
I'm new to React, and creating a simple app. The only data I need to store globally is a user object, and I would like to avoid using Redux if possible. I'm having a hard time finding info on the best way to do this + tutorials and examples. Will using a Provider from the Context API be suitable?
There is a great open source library called Unstated. It still uses a component architecture for deciding on who has access to the data, but it's a lot simpler (IMO) than redux. You could also just store something on the window object just for testing, but it's a really bad idea to do that in production.
I'm starting a new React app and, seeing all the news in the ecosystem, I want to go slow and actually consider my choices, starting with just React/Webpack/Babel, and introducing more.
The first of these choices is whether to use Flux or not (more precisely, Redux, which looks great and seems to have won the flux wars). Here is where I am:
I understand Redux's benefits, summarized on SO by Dan Abramov. They look great, but I'd rather introduce things one step at a time.
In plain React, parent→child communication is done with props, and child→parent communication happens with callbacks. See Doc / Communicate Between Components, or SO / Child to parent communication in React (JSX) without flux, or this codeacademy Redux tutorial which starts out by saying "no need for Redux if you're fine with plain React and all your data in a root component".
Which looks just fine for my purpose...
... however, the sad part is that these callbacks have to be passed down the component chain, which becomes quickly tedious as the levels of nesting grow.
To solve this without introducing new dependencies, I found two articles (1: Andrew Farmer, 2: Hao Chuan) encouraging usage of the recently-introduced context feature of React.
→ Using context would let me expose my model-mutating callbacks to my child components. To me it doesn't sound like a horrible misuse: I wouldn't be passing model data, just references to functions for binding on event handlers.
Does it sound sane?
Any other plain-React suggestion for convenient child→parent communication?
Thanks.
Answering my own question after watching Dan Abramov's Getting Started with Redux series, which I warmly recommend.
Yes it looks like it's sane: Redux faced the very same problem and solved it with Context (at least initially, the implementation may have changed). It is implemented and packaged (among other things) in the react-redux bindings under the <Provider> component and the connect() function.
Initially, at the start of step 24 - Passing the Store Down Explicitly via Props , we have a Todo app with a Redux store available as top-level variable. This sucks (for 1. testability/mockability, 2. server rendering needing "a different store instance for every request because different requests have different data"), so the store is demoted from top-level variable to a root component prop.
As in my case, having to pass the store as prop to each component is annoying, so in 25 - Passing the Store Down Implicitly via Context, Dan demonstrates using Context to pass the Redux store to arbitrarily nested components.
It is followed by 26 - Passing the Store Down with <Provider> from react-redux, explaining how this was encapsulated in the react-redux bindings.
And 27 - Generating Containers with connect() from React Redux further encapsulates generation of a container component from a presentational component.
Personally, I find the question quite simple to answer, if you think about the way dependency injection in Angular works. In Angular you have your DOM, and then you have all those services, providers, factories, constants and whatnot, which are independent of the DOM structure and can be imported simply by mentioning their name when creating modules or controllers.
I liken the use of this.context to DI. The difference w.r.t to Angular is that instead of stating the dependencies using function parameter names, you use childContextTypes and instead of getting the dependencies as function arguments, you get them through this.context.
In this sense, asking the question whether passing model mutators through this.context is sane, boils down to whether it makes sense in Angular to register your model for dependency injection. I've never seen a problem with the latter, therefore I deduce that the former is also quite OK.
I'm not saying that it suits the spirit of the library, though. Dependency injection and in particular managing dependencies between injected component is not as explicit, so one may argue that it's not the React way. I leave this philosophical discussion to others.
Tons of examples, describing React and Flux uses global variables: global Dispatcher, global Store and etc. Is there any way to proper inject dependencies to react components? There are some articles on the web describing how to use Dependency Injection component with React, but it based on undocumented weird feature called "Context" with unknown future.
Proper injection, for me, is classic constructor-based injection, without accessing global variables, without accessing static state and other.
It seems that I need to hook into component construction process (place, where new called). Can I do that? If so, how can I do that?
The most straightforward way to do dependency inversion with React is to simply pass any necessary dependencies as properties to the components that need them. Context is simply a way to pass the props down through child components, grandchild components, and so on implicitly without listing the prop on every component that may need it.
You'll find a lot of examples of this technique in the wild, and many make use of context and other niceties. React Redux is a popular one right now; pass a local variable to a top-level <Provider> component as a property, and it wires up the rest for you.
Dependency injection is less straightforward, and you'd probably need some kind of proper DI container or a DI library for JavaScript to do this nicely. Components aren't really instantiated, from the user's standpoint, the way other JS objects are, so doing "at instantiation time" injection of dependencies into components isn't how I'd approach the problem.