Redux container render a collection which parameters to pass? - redux

We are using React+Redux and it's doing well. But there is one situation I never know which strategy to use.
When I need to loop over a collection, I could write:
Pass the element
Code:
render() {
collection.map(element => <ElementItem key={element.id} element={element} />)
}
Pass the spread element
Code:
render() {
collection.map(element => <ElementItem key={element.id} {...element} />)
}
Pass the ID
Code:
render() {
collection.map(element => <ElementItem key={element.id} id={element.id} />)
}
and in ElementItem.js:
connect((state, ownProps) => {
element: state.collection.find(_el => _el.id === ownProps.id)
})(ElementItem)
All in one file:
Code:
render() {
collection.map(element => <li key={element.id}><p>{element.name}</p></li>)
}
Solution #4 is not reusable so not much interesting.
I don't like solution #2 since attributes are drowned in others
I find #3 to be the cleanest since it is the one with lesser dependencies and forwarded props. The biggest trade off is that it feels lame to launch a .find for each ElementItem
So I guess it is the first one which wins. But I have the feeling this is not the redux-way of doing things, is it? If I pass the element parameter, why wouldn't I pass more? Then we are loosing all the benefits of isolating container from presentation components, don't we ?

Solutions #1 and #2 are perfectly fine, because in that case ElementItem is a presentational component and received its data from props.
Solution #3 makes no sense, because the component looping over the collection already got the collection part of the state (either because this component is connected to Redux, or because it got it from props).
In the redux documentation, there is an example where they render a collection of todos: They use 2 presentational components: Todo, a single todo item, and TodoList, a list showing todos. Then there is a container component, VisibleTodoList, which computes the list of visible todos from the state and display them using TodoList. You could use the same strategy when you want to loop over a collection.
Another point: if you don't want to use find to get the right item, you could normalize your state, so each 'collection table' stores the items in an object with the ids of the items as keys. This way, you could get the right item like this:
const element = state.collection[elementId];

Related

Vue3 dynamically watching child component data

I'm working in Nuxt3 and I've got a slightly unusual setup trying to watch or retrieve data from child components in a complex form that is structured as a multi-step wizard. It's obviously Vue underneath and I'm using the composition API.
My setup is that I have a page the wizard component is on, and that component has a prop that is an array of steps in the wizard. Each of these steps is some string fields for titles and labels and then a component type for the content. This way I can reuse existing form blocks in different ways. The key thing to understand is that the array of steps can be any length and contain any type of component.
Ideally, I'd like each child component to be unaware of being in the wizard so it can be reused elsewhere in the app. For example, a form that is one of the steps should handle its own validation and make public its state in a way the wizard component can read or watch.
The image below explains my basic setup.
                             
The page includes this tag:
<Wizard :steps="steps" :object="project" #submit="createProject"/>
The Wizard loops over the steps to create each component.
<div v-for="(step) in steps" :key="step.name">
<component v-if="step.status === 'current'" :is="step.content.component" />
</div>
The data to setup the component with the right props for the wizard itself and the child component props.
const steps = ref([
{
name: 'overview',
title: t('overview'),
subTitle: t('projectCreateOverviewDescription'),
status: 'current',
invalid: true,
content: {
component: Overview,
props: null,
model: {}
}
},
{
name: 'members',
title: t('members'),
subTitle: t('projectCreateMembersDescription'),
status: 'upcoming',
invalid: false,
content: {
component: ThumbnailList,
props: {
objects: users,
title: t('users'),
objectNameSingular: t('user'),
objectNamePlural: t('users'),
So far I've tried to dynamically create references in the wizard component to watch the state of the children but those refs are always null. This concept of a null ref seems to be the accepted answer elsewhere when binding to known child components, but with this dynamic setup, it doesn't seem to be the right route.
interface StepRefs {
[key: string]: any
}
let stepRefs: StepRefs = {}
props.steps.forEach(step => {
stepRefs[step.name] = ref(null)
watch(() => stepRefs[step.name].value, (newValue, oldValue) => {
console.log(newValue)
console.log(oldValue)
}, { deep: true })
})
Can anyone direct me to the right approach to take for this setup? I have a lot of these wizards in different places in the app so a component approach is really attractive, but if it comes to it I'll abandon the idea and move that layer of logic to the pages to avoid the dynamic aspect.
To handle changes in child components I'd recommend to use events. You can have the children emit an event on change or completion, and the wizard is listening to events from all children and handling them respectively.
On the wizard subscribe to the event handler of the step component, and process the data coming from each step on completion (or whatever stage you need).
This way you don't need any special data type for the steps, they can just be an array. Simply use a ref to keep track of the current step. You don't even need a v-for, if you just display one step at a time. For a wizard navigation you might still need a v-for, but it would be much simpler. Please see a rough example below.
<div>
<stepComponent step="currentStep" #step-complete="handleStepComplete"/>
<div>
<wizardNavigationItemComponent v-for="step in steps" :active="step.name === currentStep.name" />
</div>
</div>
<script setup lang="ts">
const steps = step[/*your step data here*/]
const currentStepIndex = ref(0)
const currentStep = ref(steps[currentStepIndex.value])
function handleStepComplete(data) {
/* handle the data and move to next step */
currentStepIndex.value = currentStepIndex.value + 1 % steps.length
}
</script>
In the component you just need to define the event and emit it when the data is ready, to pass along the data:
<script setup lang="ts">
const emit = defineEmits<{
(event: "stepComplete", data: <your data type>): void
}>()
/* call emit in the component when its done / filled */
emit("stepComplete", data)
</script>
I hope this helps and can provide a viable path forward for you!

k6: How to create a Selection from an Element

Using Selection.each(fn) (see the k6 docs), the callback is passed an index and an Element. Element has a different API than Selection, and within the callback I’d like to use the Selection API on the passed Element so that I can operate on each Selection individually.
In jQuery, I’d often do this:
$('li').each(function (index, element) {
let container = $(element).closest('div.listContainer');
// now do something with the `container`
});
I’ve tried inside the callback to do things like $(element) or Selection(element) but it errors saying those are undefined. (Kind of stabbing in the dark, since I don’t see in the docs how to do this.)
My code looks like:
mySelection.each((index, element) => {
// here, I'd like to do element.closest('.someAncestorSelector') if element could be 'wrapped'
})
Is there a way in the jQuery-like Selection API in k6 to do this?
From the k6 docs on Selection.closest:
For each element in the set, get the first element that matches the selector by testing the element itself and traversing up through its ancestors in the DOM tree. [emphasis mine]
Which means that each is unnecessary and will be performed automatically (returning a new Selection instance with the closest elements).
const closestSelection = mySelection.closest('.someAncestorSelector');
closestSelection.each((index, closestElement) => {
// now, do something with closestElement.
});
or as a single chain of expressions:
mySelection.closest('.someAncestorSelector')
.each((index, closestElement) => {
// now, do something with closestElement.
});
Btw, even jQuery implicitly handles collections, so your jQuery code could be changed to:
const containers = $('li').closest('div.listContainer');
containers.each(function (index, container) {
container = $(container);
// now do something with the `container`
});

Dispatch redux action after apollo-react query

I want to dispatch a redux action, right after a query finishes. – where would be the right place to do this?
here I am keeping a reference to the refetch function, so that I can easily update the view with the most recent data at a later point.
export default graphql(
allFilesQuery,
{
props: ({ ownProps, data }) => {
const { dispatch } = ownProps;
dispatch(
setRefetchAllFiles(data.refetch)
);
return {
data,
...ownProps,
};
}
}
)(FileListComponent);
while this works, I also get a warning, saying:
Warning: setState(...): Cannot update during an existing state transition (such as within `render` or another component's constructor). Render methods should be a pure function of props and state; constructor side-effects are an anti-pattern, but can be moved to `componentWillMount`.
The props function is supposed to be pure and return props to inject in component without performing any kind of side effects. Actually you might be able to dispatch in it, by wrapping your dispatch in a setTimeout, but this would be a very bad idea, because the props function is run everytime your component re-renders and will likely trigger many unwanted dispatches. It could even lead to infinite loops if your dispatch makes the component re-renders.
The correct place to do what you want is in your component. You can use componentWillReceiveProps (or other lifecycle), and compare previous props to next props trigger a dispatch when appropriate. You can use data.networkStatus or data.loading for that.

Different ways of recursive data fetching with Relay? Which one is better and other questions

Recently I've made a component for recursive classifier with Relay.
I made it with two ways. One of which did not work and the second worked.
From the end-user side they both look the same with the same functionality.
In short the task is pretty much a general recursive data fetching with fetching
on next level expand.
The first way:
Fetch data after setting the relay variable expand. It is made via the
recursive fragment composition. The main part is this:
const CategoryItemContainer = Relay.createContainer(CategoryItem, {
initialVariables: {
expanded: false,
},
fragments: {
category: (variables) => Relay.QL`
fragment on Category {
id
name
hasChildren
${CategoryItemSubcategoryListContainer.getFragment('categories').if(variables.expanded)}
}
`,
},
});
const CategoryItemSubcategoryListContainer = Relay.createContainer(CategoryItemSubCategoryList, {
fragments: {
categories: () => Relay.QL`
fragment on Category {
categories(first: 10000) {
edges {
node {
${CategoryItemContainer.getFragment('category')}
}
}
}
}
`,
},
});
This way it is supposed that the Relay.RootContainer is called just once. It
did not work for me but I know that others implemented it and everything's OK (it's
a subject for another post).
The second way:
The second way worked for me easy. I don't use Relay variables but I call
Relay.Renderer for the next level of recursion depending on the UI component's
state. Like this:
{this.state.hasOwnProperty(category.id) ? // <- changing the state triggers the recursion
<Relay.Renderer
Container={CategoryItemSubCategoryListContainer}
queryConfig={new CategoryRoute({ id: category.id })}
environment={Relay.Store}
render={({ done, error, props, retry, stale }) => {
if (error) {
return 'Error';
} else if (props) {
return <CategoryItemSubCategoryListContainer {...props}
maxLevel={maxLevel}
currentLevel={currentLevel + 1}
activeCats={this.props.activeCats}
elementSelectedCallback={elementSelectedCallback}/>;
}
return (
<ul className="dropdown-menu" aria-labelledby="dLabel">
<li>
<div className="list-group-item"><p className="text-center"><img src="img/ajax-loader.gif"/></p></div>
</li>
</ul>
);
}}
/> : ''}
This works just as I expected to. Moreover I have a nice loader icon for the
next level everytime.
So, having this I've got three questions:
The first
Is any of these methods the preferrable one? Maybe there are drawbacks
somewhere that I don't know? I'd like to understand this since I'm introducing
Relay to my company and I'm willing to replace all the legacy frontend with
React and Relay.
The second
At some point in time a user will pick a category from this recursive
classifier and I will have to get the full path of data that led to the current
level.
I mean if a user picks a category at the level 3 of the hierarchy, I must give
back these data:
[root cat id, root cat name],
[level 1 cat id, level 1 cat name],
[level 2 cat id, level 2 cat name]
So when I catch the event of picking inside the component at the level 2 how can
I get the full path from the root category from Relay? I thought that I can
use some Relay API to get them from store? Or do I have to implement this
store myself?
The third
As I said in the second way of implementation there's a nice feature that I
get the loading spinner every time the Relay.Renderer is called. How can this
be done in the first way? I mean in the first way data fetching is hidden inside
fragment composition and and is triggered by the setVariables. Should I
trigger the spinner right before the setVariables method and then turn it off
in the onReadyStateChange of the only Relay.RootContainer? But then it seems
like I have to make a global store of spinners' state for rendered containers..
I'm confused here..

getMeteorData race conditions with component lifecycle?

I'm getting some pretty undesirable behavior in my app, and I'm having a hard time replicating the issue and/or figuring out what I'm doing wrong or not understanding about React that's causing my components to act this way.
What I want to do is to get some data from Mongo on the App component, then have all of that data readily available for any child that I want.
<App> //get data here, pass to children through props
<ChildElement1 data={this.data.appData}/>
<ChildElement2 data={this.data.appData}/>
<ChildElement3 data={this.data.appData}/>
</App>
Here's how I've attempted to tackle this with React so far:
App = React.createClass({
mixins: [ReactMeteorData],
getMeteorData() {
let _id = 'exampleId';
return {
appData: Collection.findOne({_id})
};
},
render() {
return (<ChildElement1 data={this.data.appData} />);
}
});
ChildElement1 = React.createClass({
getInitialState() {
return {
values: ['val1', 'val2', 'val3', 'val4'] //default values
};
},
componentWillMount() {
if(this.props.data.specificValues) {
this.setState({values: this.props.data.specificValues});
}
},
render() {
let values = this.state.values;
return (<span>{values[0]} {values[1]} {values[2]} {values[3]}</span>);
}
});
So here's where it gets weird. When I call componentWillMount(), sometimes this.props.data is defined and other times it's not, which leads me to believe there's some sort of race conditions going on where sometimes that data gets loaded correctly as a prop and other times it doesn't.
I then figured that, well okay, I can't depend on the data prop being there before the component is initially mounted, so I could instead use componentWillReceiveProps(nextProps) and check the updated props that way (and update the state, if necessary). HOWEVER! After using componentWillReceiveProps, now this.props.data is seemingly ALWAYS correctly attached to the props of ChildElement1 (which means componentWillReceiveProps doesn't run!).
My final solution was to use BOTH componentWillMount and componentWillReceiveProps to account for both situations and to do the exact same check in both locations. This fix works, but boy does it seem messy and probably indicates a lack of understanding of component lifecycles, how the meteor/react should properly interact, both, or something else completely.
I'd sure appreciate a bit of help here.
edit: I've come up with a small improvement - instead of using componentWillMount and componentWillReceiveProps to do the check to see if there are specific values defined in the Mongo Collection, I put that logic in render like so:
render() {
let data = this.props.data,
values = (data) ? data.specificValues : this.state.values;
return (<span>{values[0]} {values[1]} {values[2]} {values[3]}</span>);
}
There's definitely still some sort of underlying issue, however, as I still don't understand why this.props is so inconsistent when given data retrieved from getMeteorData. This version is a bit more succinct, however.
I found a better approach to this rather than passing the data returned from getMeteorData to each of the children as props. Using the methods described here: https://www.tildedave.com/2014/11/15/introduction-to-contexts-in-react-js.html, I explicitly listed the childContextTypes and getChildContext in <App /> and then contextTypes in <ChildElement1 />, which allows this.data.appData to be available by way of this.context in <ChildElement1 /> and presumably within any other children of <App />. Although I gotta admit, declaring every single proptype of the collection is a major PITA, seems like it'd be necessary to write a mixin (or rather, a bunch of mixins) to handle that stuff.

Resources