How can I pass props to the component that's inside the createContainer() function?
From what I see, createContainer() does not seem capable of passing props to the component.
For example, when you have:
export default createContainer(() => {
const myProp = 'one prop';
return {
my-prop: myProp,
};
}, App);
The first argument of createContainer receives a function where you can declare your props. The second argument is the component you want to wrap.
For more information, take a look in the createContainer itself:
https://github.com/meteor/react-packages/blob/devel/packages/react-meteor-data/createContainer.jsx
Related
Is there any way to tell, from within a Vue 3 component, what props are being explicitly passed in (i.e., as attributes on the component's tag in the parent template)—as opposed to being unset and receiving their value from a default?
In other words, if I have a prop declared with a default value, like this:
props: {
name: {
type: String,
default: 'Friend'
}
}
How can I tell the difference between this:
<Greeting name="Friend" />
and this:
<Greeting /> <!-- name defaults to 'Friend' -->
In both instances, the component's name prop will have the same value, in the first case being passed in explicitly and in the second case being assigned the default.
Is there a systematic way in Vue 3 to determine the difference?
In Vue 2 you could use this.$options.propsData for this purpose—it contained only the properties that were directly passed in. However, it has been removed in Vue 3.
This information may be available in component instance with getCurrentInstance low level API, but there is no documented way to distinguish default and specified prop value that are === equal.
If default prop value is supposed to differ from the same value that was specified explicitly, this means that this isn't the case for default prop value, and it should be specified in some other way, e.g. through a computed:
const name = computed(() => {
if (props.name == null) {
console.log('default');
return 'Friend';
} else
return props.name;
});
There is a way, I believe, although since it's a pretty specialised requirement, we need to directly access Vue's undocumented methods and properties, which is not considered stable (although usually fine).
<script setup>
import { getCurrentInstance, computed } from "vue";
const props = defineProps({
test: {
type: String,
default: "Hello"
}
});
const vm = getCurrentInstance();
const propDefaults = vm.propsOptions[0];
const testIsDefault = computed(() => propDefaults.test.default === props.test);
</script>
My project is based on Vue3 and I use the component called 'el-tree' provided by 'element-plus'. For accessing I define a variable called 'tree' which value is ref(null) in setup() method. Then I wrote an attribute ref called 'tree' in 'el-tree' in my template code.
I think that the ref value of 'tree' in the whole setup() method is null. But why it has value when I log it in the callback function of promise.
template
<template>
<el-card>
<el-tree
:data="menuTreeList"
show-checkbox
default-expand-all
node-key="id"
ref="tree"
highlight-current
:props="defaultProps">
</el-tree>
</el-card>
</template>
setup() method
setup(){
...
const tree = ref(null)
const puzzleValue = function(){
console.log(tree.value) // null
Promise.resolve().then(()=>{
console.log(tree.value) //Proxy{}
})
}
puzzleValue()
...
}
You are accessing tree right after defining it but before the component is created, that's why it is still not a Proxy. All your ref will become Proxy after your components are created. That is why you can see the change in value when the promise resolves.
In order for this to not happen, you should make sure to never access your refs right after defining them in the setup function. Use always a lifecycle hook for that:
setup(){
const tree = ref(null)
const puzzleValue = function(){
console.log(tree.value)
Promise.resolve().then(()=> {
console.log(tree.value)
})
}
onMounted(() => puzzleValue()) // now, tree.value will be a Proxy consistently
}
Normally with navigation you receive the props on child component like this, with the curly braces:
const MatchHistoryScreen = ({ navigation, route }) => {
But I believe props you do without the curly braces, like this:
const MatchToggleComponent = (props) => {
So how do you combine both 'navigation' and 'props' for a child component? Putting 'props' in curly braces did not work for me. I think a potential use case for this is if you are passing down props from App.js together with your navigation prop.
So the props object is what a component receives from React depending on how you have configured your app. If you have Redux, then you are going to receive some props from there. If the component is a child, and you are passing some properties from the parent, you are going to receive props from the father too. If the parent is passing navigation, then you will have it as props in your child.
props is just an object that a component receives from multiple sources. It can actually be called anything, banana or sporp, it's just a convention to call that object props.
Destructuring on the other hand is used to "unpack" properties of an object (or values from an array) into separate variables. So when you are unpacking the navigation properties, you are essentially going from
const MatchToggleComponent = (props) => {
// props object contains navigation and route properties, which can be accessed as props.navigation and props.route
into
const MatchToggleComponent = ({ navigation, route }) => {
// you unpack navigation and route properties into separate variables `navigation` and `route`, ready to be used in your component.
Imagine that the parent of MatchToggleComponent looks like
return (
<>
<MatchToggleComponent
foo={bar}
one={two}
/>
</>
)
So your props object is going to have the foo property, one property, and then navigation property and route property. Destructuring effectively let's you pick the properties that interest you and "unpack" them, ready to be used inside your component without referencing the props object all the time.
So if you wanted to use foo prop, AND your navigation props, you would do
const MatchToggleComponent = ({ foo, navigation, route }) => {
You could do that in any component, just try it out.
If you have any additional questions please don't hesitate to continue the discussion :)
Edit 1:
req.query seems to be an object with properties userId and activeMethods. When you destructure the object, you should be using curly braces. Consequently, when you destructure arrays, you should be using square brackets [].
The variable names that you destructure should be called the same as in the objects. For example:
const foo = {
some: ...,
other: ...,
last: ...,
};
If you do const { bar } = foo, then JS is not going to know that you want to get the first prop of the object and this will throw an error. So the variable you create should match the prop name in the object, like
const { last, other } = foo;
As you can see, the order doesn't really matter (the situation is a bit different with arrays, but I won't be covering this here).
What you can do is that you can rename the variable WHILE destructuring properties from the object. Imagine you want to get the last prop from the foo object, but you want it named first for some reason. Then you would do
const { last: first } = foo;
This will effectively unpack the last prop from the foo object for you and rename it into first, so you'll be able to use const first across your code.
You can do it with using useNavigation hook which gives access to navigation object.
example:
import { useNavigation } from '#react-navigation/native';
function MyBackButton() {
const navigation = useNavigation();
return (
<Button
title="Back"
onPress={() => {
navigation.goBack();
}}
/>
);
}
Suppose I have a prop named message which I want to access from the script section of a .vue file.
I know that it can be accessed using this.$props.message and this.message from the data function.
Which is the preferred way to access props from different lifecycle hooks (created, mounted, etc), and from computed getters, and methods?
Component properties as well as passed in props should always be referenced to by this.propName, because you shouldn't assign a component property with the same name as a passed in prop. In this case Vue will respond with an error.
As Aer0 said, they shouldn't have the same names:
props: ['propMessage'],
data() {
return {
message: ''
};
},
created() {
console.log(this.propMessage);
console.log(this.message);
}
I'm wanting to assert that a component gets called from within another component with the correct arguments.
So within the component that I am testing there is a Title component that gets called with properties title & url. I'm trying to assert that it gets called with the correct arguments.
I'm pretty sure I want to use a sinon spy and do something like this
const titleSpy = sinon.spy(Title, render)
expect(titleSpy).to.be.calledWith( '< some title >' )
but with regards to React and Enzyme, I'm not really sure what I should be spying on. (Because apparently it's not render!)
In my spec file I am importing Title and console.loging it's value to find a function to spy on and I get:
function _class() {
_classCallCheck(this, _class);
return _possibleConstructorReturn(this, Object.getPrototypeOf(_class).apply(this, arguments));
}
Any ideas on how I can do this? Is it a case of going through and finding the element and checking it's attributes? If so that seems a bit...messy and seems like it goes against the principle of the Shallow render ("Shallow rendering is useful to constrain yourself to testing a component as a unit").
If you're just checking the value of properties passed to the component, you don't need sinon. For example, given the following component:
export default class MyComponent extends React.Component {
render() {
return (
<MyComponent myProp={this.props.myProp} />)
}
}
Your test might look like this:
describe('MyComponent ->', () => {
const props = {
myProp: 'myProp'
}
it('should set myProp from props', () => {
const component = shallow(<MyComponent {...props} />)
expect(component.props().myProp).to.equal(props.myProp)
})
})
You can achieve it with the help of .contains() method, without messing up with spies.
If you have a component:
<Foo>
<Title title="A title" url="http://google.com" />
</Foo>
You can make such an assertion:
const wrapper = shallow(<Foo />);
expect(wrapper.contains(<Title title="A title" url="http://google.com" />)).to.equal(true);
Such will fail:
const wrapper = shallow(<Foo />);
expect(wrapper.contains(<Title title="A wrong title" url="http://youtube.com" />)).to.equal(true);
This is an older question, but my approach is a little different than the existing answers:
So within the component that I am testing there is a Title component that gets called with properties title & url. I'm trying to assert that it gets called with the correct arguments.
ie. You're wanting to check that the component being tested renders another component, and passes the correct prop(s) to it.
So if the component being tested looks something like:
const MyComp = ({ title, url }) => (
<div>
<Title title={title} url={url} />
</div>
)
Then the test could look something like:
import Title from 'path/to/Title';, u
it('renders Title correctly', () => {
const testTitle = 'Test title';
const testUrl = 'http://example.com';
const sut = enzyme.shallow(<MyComp title={testTitle} url={testUrl} />);
// Check tested component rendered
expect(sut.exists).toBeTruthy();
// Find the Title component in the subtree
const titleComp = sut.find(Title); // or use a css-style selector string instead of the Title import
// Check that we found exactly one Title component
expect(titleComp).toHaveLength(1);
// Check that the props that were passed were our test values
expect(titleComp.prop('title')).toBe(testTitle);
expect(titleComp.prop('url')).toBe(testUrl);
});
I generally find Enzyme's functions to be very useful for all kinds of checks about components, without needing other libraries. Creating Sinon mocks can be useful to pass as props to components, to (for example) test that a callback prop is called when a button is clicked.