I'm following the official meteor guide 1.3 and how to integrate react. The guide doesn't thoroughly explain the usage of container pattern. My question is how to pass parent component data to child component's container so that I can write subs with parent's _id parameter? Or am I wrong with this pattern? Should I just write one big publications that publishes all child components' data too? In blaze you have Template.parent.data() function. I'm new to React so excuse me.
Related
I've tried to solve it in different ways but I couldn't. Is there any simple way to use Konva.js with Redux and React Hooks.
As I read about, Konva's context mechanism is different from React-Redux. And so, even though my all App in Provider wrapper, React child components that I used with Konva, doesn't see the wrapper.
When I apply Provider wrapper again in child component, inner the konva's Stage tag, the app didn't give any error and worked but reducer states entered the loop somehow. I believe the provider in child components does its job but after that global provider does its job again and changes reducer states as initial states.
To fix this I tried to add another reducer and store but the same again.
I kindly ask anyone who can help and also Dear Konva Contributors :) please give a new sample to use for 2021 with react hooks.
Turns out I should have just used ReactReduxContext.Consumer, as described below.
https://github.com/konvajs/react-konva/issues/311#issuecomment-454411007
I am not sure if I am missing something within the Next.js documentation, but it seems as if it is unfeasible to reuse components within a Next.js application without breaking the component.
So from my understanding:
Next.js uses SSR to fetch data at a pages level by either getStaticProps, getStaticPaths or getServerSideProps.
Once this data has been fetched it is returned to the page via props.
The page then has access to the props and can then handle this data however it wants.
In order to use the SSR techniques for child components of our page we have to grab the child components data at page level and then pass this data down to our components.
This raises some concerns for me and questions:
This means our children components always have a dependency on the parent page?
We can't reuse our components on other pages without repeating logic or breaking components?
How do I reuse components without client side rendering?
Could I just grab everything at the entry point of the app and then store this in various state variables using Redux and call them at component level when needed?
By using client side rendering it sort of defeats the purpose of using Next.js. Yes, I can just use a useEffect hook to grab the data at component level but this doesn't seem right to me.
Am I missing something in the architectural pattern or is this just a vulnerability when working with Next.js?
The more I think about this the more I realise Relay and GraphQL are the future.
When using Redux with React we're able to use react-redux which internally uses React's context API to make the store available to all HoCs created with connect.
I'm playing around with Web Components to evaluate how feasible it is to use primarily Web Components for building your application but still wanted a way to deal with state management (in Polymer they recommed using the mediator pattern and Redux is a type of global mediator).
So far I'm able to have a component create the store and pass it to a child component to use. This has the limitation that I will need to pass around the store to every container component, and even pass it through presentational components if they need to then pass it to another container.
So what I want to achieve is a way to make the store available to all container components that live under the Store component in the tree, preferably without making the store a global variable.
I imagined creating something similar to the react-redux connect component but since that one relies on React context I'm trying to find ideas for how to create a shared object.
Wrapping your class in an iife function and declaring a variable outside of the scope of the class as well as assigning a property of the class to the external variable will create a singleton mechanism for sharing data between instances of an element. You would then include that element inside of the template of any other element and bind to it normally. Here's an example: https://github.com/firmfirm/f-singleton/blob/master/f-singleton.html
I am building an React+Redux application, I come to the point where I am
considering to use a container inside another container. I am asking myself if
this is a good approach, ie. is it good practice, or should we strictly follow the rule of 1 container with several components ?
Let me quote Dan Abramov's article about presentational- and container- components:
When you notice that some components don’t use the props they receive but merely forward them down and you have to rewire all those intermediate components any time the children need more data, it’s a good time to introduce some container components. This way you can get the data and the behavior props to the leaf components without burdening the unrelated components in the middle of the tree.
...meaning it is perfectly fine to have a container component inside another container component if you feel the need for it.
It's not easy to find which component should stay "dumb" and which component should be aware of application and become a container. I don't think it's a problem / anti-pattern to use a container in another one. If a part of your application is used on different pages it can be a container, be connected and use in differents pages/containers, Just be aware : this "container component" will specific to this application
I'm trying to create a custom grid in Rally to filter Tasks on the tags of both the task parent and/or the parent of the parent. I'm able to get the parent's tag, but not the syntax of the parent of the parent.
Unfortunately you'll have a hard time doing this with the custom grid app. The problem is that the WorkProduct field that represents the Task's parent is of type Artifact since it can be either a story or a defect. But Artifact doesn't have a Parent field.
It should be possible to write an app to do this though, by querying from the other direction- find features with a specific tag and load their children, find stories with a specific tag, and then load all of the children tasks associated with those stories...