In Svelte, I have a parent component which listens to a component event dispatched by a child component.
I know how to use component.$on to check that the dispatched event does the right thing within the component which is dispatching, like so.
But I can't figure out how to check that the component which receives the dispatch does the right thing in response.
Here's a basic example:
Child.svelte
<script>
import { createEventDispatcher } from 'svelte'
const dispatch = createEventDispatcher()
function handleSubmit(event) {
dispatch('results', 'some results')
}
</script>
<form on:submit|preventDefault={ handleSubmit }>
<button type='submit'>Submit</button>
</form>
Parent.svelte
<script>
import Child from './Child.svelte'
let showResults = false
function handleResults(event) {
showResults = true
}
</script>
<Child on:results={ handleResults } />
{ #if showResults }
<p id='results'>Some results.</p>
{ /if }
The idea is to eventually write a test using #testing-library/svelte like:
import { render } from '#testing-library/svelte'
import Parent from './Parent.svelte'
test('shows results when it receives them', () => {
const rendered = render(Parent)
// ***
// Simulate the `results` event from the child component?
// ***
// Check that the results appear.
})
If the parent were reacting to a DOM event, I would use fireEvent.
But I don't know how I would get a hold of the <Child> component in this case, and even if I could I'm guessing that Svelte is using a different mechanism for component events.
(Just to test it out, I used createEvent to fire a custom results event on one of the DOM elements rendered by <Child> but it didn't seem to do anything.)
Anyone have any ideas? Thanks!
If you're already planning on using #testing-library/svelte, I think the easiest way is not to try to manually trigger the Child component's results event, but to use Testing Library to grab the form/submit elements and trigger the submit event (using fireEvent a SubmitEvent on the <form> or their #testing-library/user-event library, or even a vanilla dispatchEvent). Svelte would then dispatch the custom results event that Parent is listening on.
Something like:
test('shows results when it receives them', async () => {
// Arrange
const rendered = render(Parent)
const submitButton = rendered.getByRole('button', {
name: /submit/i
});
const user = userEvent.setup();
// Act
await user.click(submitButton);
// Assert
const results = rendered.queryByText(/some results\./i);
expect(results).not.toBe(null);
});
Hope this is what you had in mind.
Edit:
For mocking Child.svelte, something like this in a __mocks__/Child.svelte should work:
<script>
import { createEventDispatcher } from "svelte";
const dispatch = createEventDispatcher();
function handleSubmit(event) {
dispatch("results", "some results");
}
</script>
<form on:submit|preventDefault={handleSubmit}>
<button type="submit">Test</button>
</form>
Which is the exact same implementation as the actual module (I gave the button a different label just to make it clear it's the mocked version when querying it), but the idea is that this would never need to change and is only used to dispatch a results event. Then you'd just need to tell Jest or whatever you're using that you're mocking it (jest.mock("./Child.svelte");), change the getByRole query to match the new name (or just leave the mock with the original name), then it should just work.
Whether you think that's worth it or not is up to you. I've generally had success testing the UI as a whole rather than mocking sub-components, but I guess it comes down to preference. Yes, you might have to change the test if the Child component changes, but only if you change the label of the button or change the user interaction mechanism.
You don't need to know about the details of the components, you don't even need to know that it's split into a separate Child component, all the test would care about is a general idea of the structure of the UI—that there's a button called "Submit" and that clicking on it should show an additional <p> tag.
Related
I watch a property of an object device.flow. When the property changes, the callback gets triggered. That all works and is fine.
I only want though that the callback gets triggered if the user actually manipulates the form component that uses that watched property as model.
There's also a periodic API call to get the current data of the device as it might change due to other circumstances than just user input. The slider should then adjust accordingly as well but the web socket event should not be emitted because that is unnecessary.
To illustrate what I want to achieve, I attached a simple component below and added a comment, where I want to distinguish the source of the property change.
Is this even possible?
<script setup lang="ts">
import type DeviceAirValve from "../../../model/DeviceAirValve";
import {reactive, ref, watch} from "vue";
import {useSocketIO} from "../../../plugins/vueSocketIOClient.js";
import type {Socket} from "socket.io-client";
interface Props {
device: DeviceAirValve
}
const props = defineProps<Props>();
const io = useSocketIO() as Socket;
let device = reactive<DeviceAirValve>(props.device);
watch(
() => device.flow,
flow => {
// Determine whether the callback gets called because
// the value was changed by the user through the v-slider component,
// or if the device.flow property has been updated by something else
// (for example a periodic poll from an API) -> isFormInput variable
if (isFormInput) {
flowChangeHandler(flow)
}
}
);
const flowChangeHandler = (newFlow: number): void => {
io.emit('deviceUpdate', {
deviceId: props.device.deviceId,
data: {flow: newFlow}
});
};
</script>
<template>
<v-slider v-model="device.flow"></v-slider>
</template>
One solution is to replace the watcher with an event handler for v-slider's update:modelValue event (the event that drives v-model, which is only triggered by user input):
<v-slider #update:modelValue="flowChangeHandler" />
demo
I have a test like this:
it('Side effect should trigger', async ()=>{
await act(async () => {
let container = render(<Grandparent/>);
const btn = container.findByTestId('childBtn');
fireEvent.click(btn)
});
const changedMsg = await container.findByText('Changed');
expect(changedMsg).toBeInTheDocument();
})
My components look like this:
Grandparent:
const Grandparent = ()=>{
const [labelText, setLabelText] = useState('Unchanged');
return (<Parent labelText={labelText} setLabelText={setLabelText}/>);
}
Parent:
const Parent = ({labelText, setLabelText})=>{
return (<div>
<label>{labelText}</label>
<Child setLabelText={setLabelText} />
</div>)
}
Child:
const Child = ({setLabelText}) =>{
return(<div>
<Button data-testid='childBtn' onClick={()=>setLabelText('Changed')}/>
</div>)
}
My issue is that the assertion in my unit test fails. I've logged the return value from findByTextId('childBtn') and I am indeed getting a button (something like <button class='MuiButtonBase-root' data-testid='childBtn'></button>), but the side effect from clicking it is not going through. I added some logging in the onClick function and it never showed up when I re-ran the test, so the issue is that the onClick handler isn't firing at all.
How do I fix this? Is trying to test something that involves side effects from a bunch of nested components like this not feasible in the first place?
EDIT: I think you have some code mistakes in your unit test since you are mixing react-testing-library API and testing-library, try this:
it("Side effect should trigger", async () => {
const {findByTestId, findByText} = render(<Grandparent />);
fireEvent.click(await findByTestId("childBtn"));
const changedMsg = await findByText("Changed");
expect(changedMsg).toBeInTheDocument();
});
});
I did not test it, but it should work.
act() wrapper is not needed in react-testing-library since the render method is using it internally.
With react-testing-library you dont' have to care about implementation details of your components, nor you care to test internal state, etc... You just test "What the end user sees on screen in response to certain events". If you need to test functions, like fetch, interactions with global object, etc... you need to mock all those methods.
The philosophy of this approach is to make your unit tests ( which are never funny to write ) so that they won't have to change too often even if you are going to refactor your React Components. You just care about what it' s being rendered as DOM nodes and that's what you have to test.
NOTE: In the code you pasted there are typos btw, props have to be destructured in your code if you want to use them directly without doing props.prop, like : const Child = ({setLabelText}) =>{ .
I am looking for a solution in which a user can enter text into an input, and when they click anywhere outside of the component, it submits, saves the value.
In my case I have a top level component which dynamically generates Text Input components.It passes in the properties including an UpdateValue function.
In these functional components I am using the ability to add an event listener to the document, and then I detect if the click comes from outside the component in question. Having done a lot of research on stackoverflow, this seems to be the agreed upon method.
useEffect(() => {
document.addEventListener('mousedown', handleClick);
return () => {
document.removeEventListener('mousedown',handleClick);
}
},[])
const handleClick = (e) => {
if(node.current.contains(e.target))
{
return;
}
updateValue()
}
I have this working, in that the function gets called when I click outside the component, however, the function invoked on the parent component no longer seems to have access to the state..they appear all empty. I can only guess that because we are using a generic javascript function initially, the call doesn't have access to react stack.
So, my question is, how can I make this work where I want a nested functional component that has an input, and when a user clicks off component, it runs the updateValue function which can then use some internal state data to properly update this in the DB.
FYI, I have a onchange() on the input, which updates the value in the parent component already.
So, UpdateValue() is a trigger to basically submit final changes to DB.
Your updateValue should be a callback that you create inside your functional component. That should take dependencies on the state that you define there. Use React.useCallback
intro:
I want to test that if I click on the submit button, the onSubmit function is called. I assume this is possible from what I understand when I read the documentation:
https://sinonjs.org/releases/v6.1.5/spies/
https://vue-test-utils.vuejs.org/guides/#testing-key-mouse-and-other-dom-events
expected output:
get the test to run and show me either pass or fail
actual output:
none, I'm currently stuck at the following:
context:
in my test:
import NavBar from '#/components/layout/NavBar.vue'
in that component I have a (simplified version here) form:
<b-nav-form #submit="onSubmit">
<b-form-input />
<b-button type="submit">Search</b-button>
</b-nav-form>
I want to test that if I click on the submit button, the onSubmit function is called.
My setup is Vue, BootstrapVue and Sinon. I understand I have to setup a spy that listens to a function being called.
This is the actual script in my component if that is helpful:
<script>
export default {
data () {
return {
query: ''
}
},
methods: {
onSubmit () {...}
}
}
</script>
example that I understand:
it('a true example', () => {
var f = {
onSubmit: function(query) {
this.query = query;
}
}
var onSubmitSpy = sinon.spy(f, 'onSubmit');
f.onSubmit('Club')
console.log(onSubmitSpy.callCount); // is 1
onSubmitSpy.restore();
})
But this is not connected to for example clicking on the button in the form.
Please advise
The idea to test functions of vue components to have been called is to:
Create testing components with vue-test-utils mount or shallowMount.
Pass a methods param in the options to provide spies.
Perform actions in the component that calls the spied method, then assert the method was really called.
I don't have sinon experience, am only used to test vue components with jest, but the thing should be something like the following:
import NavBar from '#/components/layout/NavBar.vue'
import {shallowMount} from 'vue-test-utils';
it('asserting onSubmit calls', () => {
// given
var onSubmit = sinon.spy();
var wrapper = shallowMount(NavBar, {
methods: {
onSubmit();
}
});
var vm = wrapper.vm;
// when
vm.onSubmit();
// then (I dont really dont know if this is valid sinon syntax)
assertTrue(onSubmit.called);
// or, with jest syntax:
// expect(onSubmit).toHaveBeenCalled();
})
Now, the code snippet should work, but there are problems with this test: we are asserting that when we call the component onSubmit, the onSubmit spy gets called. This is not the great thing.
Your test would probably need to assert somehing like: when the <b-nav-form> component emits a submit event, then the onSubmit spy gets called.
That would be a more complex test, for two reasons:
Because a child component is involved. To really render child components in a vue-test-utils test, you need to use mount instead of shallowMount. This is difficult as you need to provided childs props and dependencies, so get used to the shallowMount and mount differences.
When you start testing events, chances are some synchrony is involved, so you need to wait for the event to propagate and get your component method called. This usually involves to pass done callback to it() blocks.
I am using react, react-router & redux. The structure of my app is such:
CoreLayout
-> <MaterialToolbar /> (contains back button)
-> {children} (react-router)
When the user presses the back button, which is normally handled by the CoreLayout, I would like the current child component to handle the back button instead of the parent. (In my case, I would like the current view to check if its data has been modified, and pop up an 'Are you sure you wish to cancel?' box before actually going back.) If the child does not wish to handle this, the parent will do it's thing.
Another example would be allowing a childview to set the title in the toolbar.
My reading has told me that accessing a component through a ref and calling a method on it is not the react way -- this is also made a bit more difficult since I am using redux-connect. What is the correct way to implement this behavior?
This is how I would do it, assuming you mean your navigation back button (and not the browser back button):
class CoreLayout extends Component {
handleBack () {
//... use router to go back
}
render () {
return <div>
<MaterialToolbar />
{React.children.map(this.props.children, child => React.cloneElement(child, { onBack: this.handleBack }))}
</div>
}
}
class Child extends Component {
handleBackButtonClick () {
// Here perform the logic to decide what to do
if (dataHasBeenModifiedAndConfirmed) {
// Yes, user wants to go back, call function passed by the parent
this.props.onBack()
} else {
// User didn't confirm, decide what to do
}
}
render () {
return <div onClick={this.handleBackButtonClick.bind(this)}>
Go Back
</div>
}
}
You simply pass a function from the parent to the child via props. Then in the child you can implement the logic to check if you really want to delegate the work to the parent component.
Since you use react-router and your children are passed to your parent component through this.props.children, to pass the onBack function you need to map the children and use React.cloneElement to pass your props (see this answer if you need more details on that: React.cloneElement: pass new children or copy props.children?).
Edit:
Since it seems you want to let the children decide, you can do it this way (using refs):
class CoreLayout extends Component {
constructor () {
super()
this.childRefs = {};
}
handleBack () {
for (let refKey in Object.keys(this.childRefs) {
const refCmp = this.childRefs[refKey];
// You can also pass extra args to refCmp.shouldGoBack if you need to
if (typeof refCmp.shouldGoBack === 'function' && !refCmp.shouldGoBack()) {
return false;
}
}
// No child requested to handle the back button, continue here...
}
render () {
return <div>
<MaterialToolbar />
{React.children.map(this.props.children, (child, n) => React.cloneElement(child, {
ref: cmp => { this.childRefs[n] = cmp; }
}))}
</div>
}
}
class Child extends Component {
shouldGoBack () {
// Return true/false if you do/don't want to actually go back
return true
}
render () {
return <div>
Some content here
</div>
}
}
This is a bit more convoluted as normally with React it's easier/more idiomatic to have a "smart" parent that decides based on the state, but given your specific case (back button in the parent and the logic in the children) and without reimplementing a few other things, I think using refs this way is fine.
Alternatively (with Redux) as the other answer suggested, you would need to set something in the Redux state from the children that you can use in the parent to decide what to do.
Hope it's helpful.
I don't think there is a correct way to solve this problem, but there are many ways. If I understand your problem correctly, most of the time the back button onClick handler will be handled within CoreLayout, but when a particular child is rendered that child will handle the onClick event. This is an interesting problem, because the ability to change the functionality of the back button needs to be globally available, or at very least available in CoreLayout and the particular child component.
I have not used redux, but I have used Fluxible and am familar with the Flux architecture and the pub/sub pattern.
Perhaps you can utilize your redux store to determine the functionality of your back button. And your CoreLayout component would handle rendering the prompt. There is a bug with the following code, but I thought I would not delete my answer for the sake of giving you an idea of what I am talking about and hopefully the following code does that. You would need to think through the logic to get this working correctly, but the idea is there. Use the store to determine what the back button will do.
//Core Layout
componentDidMount() {
store.subscribe(() => {
const state = store.getState();
// backFunction is a string correlating to name of function in Core Layout Component
if(state.backFunction) {
// lets assume backFunction is 'showModal'. Execute this.showModal()
// and let it handle the rest.
this[state.backFunction]();
// set function to false so its not called everytime the store updates.
store.dispatch({ type: 'UPDATE_BACK_FUNCTION', data: false})
}
})
}
showModal() {
// update state, show modal in Core Layout
if(userWantsToGoBack) {
this.onBack();
// update store backFunction to be the default onBack
store.dispatch({ type: 'UPDATE_BACK_FUNCTION', data: 'onBack'})
// if they don't want to go back, hide the modal
} else {
// hide modal
}
}
onBack() {
// handle going back when modal doesn't need to be shown
}
The next step is to update your store when the child component mounts
// Child component
componentDidMount(){
// update backFunction so when back button is clicked the appropriate function will be called from CoreLayout
store.dispatch({ type: 'UPDATE_BACK_FUNCTION', data: 'showModal'});
}
This way you don't need to worry about passing any function to your child component you let the state of the store determine which function CoreLayout will call.