DEV Community: quyet

React vs Vue: Passing Functions to Child Components vs Emitting Events

quyet — Sat, 08 Apr 2023 16:07:20 +0000

Introduction:

React and Vue are two popular JavaScript frameworks for building user interfaces. One of the key differences between these frameworks is the way they handle communication between parent and child components. In this post, we'll explore two approaches: passing functions from parent to child components in React, and emitting events from child to parent components in Vue.

React Approach:

In React, data flows from parent components to child components through props. If a parent component wants to pass a function to a child component, it can do so by defining the function in the parent component and passing it down to the child component as a prop. The child component can then use this function as an event handler for user interactions.

While this approach is simple and straightforward, it can lead to a tight coupling between parent and child components. If the child component needs to access a different function or piece of data from the parent component, the parent component may need to be modified. This can make the code harder to maintain and extend.
For example:

/** Parent1 */
const Parent1 = () => {
    const doSomething = () => {}
    return <ReusableComponent doSomething={doSomething} />
}

/** Parent2 */
const Parent2 = () => {
    const doSomethingElse = () => {}
    return <ReusableComponent doSomething={doSomethingElse} />
}

Vue Approach:

In Vue, child components are designed to be more independent, and they communicate with parent components through events. If a child component wants to notify a parent component of an event, it can emit a custom event with a payload. The parent component can then listen for this event and respond accordingly.
For example

/** Parent1 */
<script setup>
function doSomething() {}
</script>
<template>
    <ReusableComponent @on-sth-happen="doSomething" />
</template>

/** Parent2 */
<script setup>
function doSomethingElse() {}
</script>
<template>
    <ReusableComponent @on-sth-happen="doSomethingElse" />
</template>

This approach promotes a separation of concerns between parent and child components, making it easier to maintain and extend the codebase. It also allows child components to be reused in different contexts without having to modify the parent components.

Conclusion:

Both React and Vue provide powerful and flexible ways to build user interfaces, and the choice of framework largely depends on the specific needs of your project. However, when it comes to communication between parent and child components, Vue's event-driven architecture provides a more modular and scalable approach, while React's prop-passing approach may lead to tighter coupling between components.

Both React or Vue are able to deliver same thing. But what I want to highlight here is about the flavor of using event-driven approach here making code looks cleaner more reasonable.

The Vue's way always make sure Child components are not coupling to the parent in a way calling parent methods where React's way allowed that to happened.

It's worth to note that event naming convention in Vue is important because it's quite easy to make naming mistake for forks coming from React world. But the design intension is clearly different, Vue is more close to the way native HTML tag communicate and React is a bit weird where it allows child component calling parent methods via props.

Let me know your thoughts on this!

Better way to handle visibility states on UI

quyet — Sat, 08 Apr 2023 03:03:43 +0000

When building user interfaces, it's often necessary to manage toggle states for different components. Toggles can represent various UI elements, such as modals or loading indicators, that can be either visible or hidden.

Traditionally, booleans have been used to manage toggle states in UI components. For example, a boolean value can be used to indicate whether a modal is visible or hidden. However, using a boolean value can have limitations, especially when dealing with more complex components that have multiple toggle states.

In this blog post, we'll explore how using strings can provide more flexibility and control over toggle UI state. We'll look at an example of a parent component that contains visibility state of multiple modals (delete/edit/new) and loading statuses using boolean and using string at the same time.

Using Booleans for Toggle UI State

Let's consider a scenario where we have a parent component that manages the visibility state of three modals - delete, edit, and new. We can use a boolean value for each modal to indicate whether it's currently visible or hidden.

Here's an example code snippet:

<script setup lang="ts">
import { ref, onMounted } from "vue"
type Member = {
    id: number
    name: string
}
const isLoading = ref(false)
const isDeleteModalVisible = ref(false)
const isEditModalVisible = ref(false)
const isNewModalVisible = ref(false)
const members = ref<Member[]>([])
const selectedMember = ref<Member | null>(null)

function onMemberSelected(member: Member) {
    selectedMember.value = member
}

onMounted(async () => {
    isLoading.value = true
    members.value = await fetchMembers()
    isLoading.value = false
})
</script>
<template>
    <Spinner v-if="isLoading" />
    <div v-else>
        <MemberList :members="members" @member-selected="onMemberSelected" />
        <button @click="isDeleteModalVisible = true">Delete</button>
        <button @click="isEditModalVisible = true">Edit</button>
        <button @click="isNewModalVisible = true">New</button>
        <DeleteModal :visible="isDeleteModalVisible" @done="isDeleteModalVisible = false" />
        <EditModal :visible="isEditModalVisible" @done="isEditModalVisible = false" />
        <NewModal :visible="isNewModalVisible" @done="isNewModalVisible = false" />
    </div>
</template>

While this approach works for simple components with just a few toggle states, it can become unwieldy for more complex components that have multiple possible toggle states.

Using Strings for Toggle UI State

Now, let's consider the same scenario but using strings instead of booleans to manage the toggle UI state. Instead of a boolean value, we can use a string value to represent the current state of each modal.

Here's an example code snippet:

<script setup lang="ts">
import { ref, onMounted } from "vue"
type Member = {
    id: number
    name: string
}
enum UIState {
    idle = "idle",
    loading = "loading",
    showingDeleteModal = "showingDeleteModal",
    showingEditModal = "showingEditModal",
    showingNewModal = "showingNewModal",
}
const uiState = ref<UIState>(UIState.loading)
const members = ref<Member[]>([])
const selectedMember = ref<Member | null>(null)

function onMemberSelected(member: Member) {
    selectedMember.value = member
}

onMounted(async () => {
    uiState.value = UIState.loading
    members.value = await fetchMembers()
    uiState.value = UIState.idle
})
</script>
<template>
    <Spinner v-if="uiState === UIState.loading" />
    <div v-else>
        <MemberList :members="members" @member-selected="onMemberSelected" />
        <button @click="uiState = UIState.showingDeleteModal">Delete</button>
        <button @click="uiState = UIState.showingEditModal">Edit</button>
        <button @click="uiState = UIState.showingNewModal">New</button>
        <DeleteModal :visible="uiState === UIState.showingDeleteModal" @done="uiState = UIState.idle" />
        <EditModal :visible="uiState === UIState.showingEditModal" @done="uiState = UIState.idle" />
        <NewModal :visible="uiState === UIState.showingNewModal" @done="uiState = UIState.idle" />
    </div>
</template>

It's worth to note that using Boolean state to handle visibility states together might lead to unexpected state (edit modal and delete modal can be true at the same time). But when using String state, this can't be happening.

Conclusion

In conclusion, while using booleans to manage toggle UI state is a common approach, using strings can provide more flexibility and control, especially when dealing with complex components that have multiple possible toggle states.

The pattern to make your FE tests 10x better.

quyet — Fri, 07 Apr 2023 09:04:10 +0000

Encapsulating Test Expects and Actions in Separate Functions

Writing test cases for your code can be a tedious task, especially when you have to test multiple scenarios with various inputs and outputs. However, there are ways to make your test cases more organized, easier to read, and maintainable.

One of the approaches is to encapsulate your test expects and actions in separate functions. This approach can improve your test code quality, reduce code duplication, and promote reusability.

Here's how you can do it:

Encapsulating Test Expects

When you write test cases, you need to assert that certain conditions are met or certain values are returned. Instead of scattering your expect statements throughout your test case, you can encapsulate them in a separate function.

For example:

const initExpects = (wrapper) => {
  const expectMessage = (message) => {
    expect(wrapper.find('.message').text()).toBe(message)
  }

  const expectButtonVisible = (buttonName) => {
    expect(wrapper.find(`button.${buttonName}`).exists()).toBe(true)
  }

  // ...

  return {
    expectMessage,
    expectButtonVisible,
    // ...
  }
}

In the above code, initExpects is a function that takes a wrapper object and returns an object that contains various expect functions. These functions can be reused in other test cases as well.

It's worth noting that the expects object can include expectations not only for the UI but also for the store, since integration testing allows us to test the interaction between different components and modules in the application.

Encapsulating Test Actions

Similarly, you can encapsulate your test actions in a separate function as well. Test actions are the functions that simulate user interactions on your component or application, such as clicking a button or typing into an input field.

Here's an example:

const initActions = (wrapper) => {
  const clickButton = (buttonName) => {
    wrapper.find(`button.${buttonName}`).trigger('click')
  }

  const setInputValue = (inputName, value) => {
    const input = wrapper.find(`input[name="${inputName}"]`)
    input.setValue(value)
  }

  // ...

  return {
    clickButton,
    setInputValue,
    // ...
  }
}

In the above code, initActions is a function that takes a wrapper object and returns an object that contains various action functions. These functions can be used to simulate user interactions in your test cases.

Putting it All Together

Here's how you can use the initExpects and initActions functions in your test cases:

describe('My Component', () => {
  let wrapper
  let actions
  let expects

  beforeEach(() => {
    wrapper = shallowMount(MyComponent)
    actions = initActions(wrapper)
    expects = initExpects(wrapper)
  })

  it('displays message when there are no todos', () => {
    expects.expectMessage('No todos yet.')
    expects.expectButtonVisible('add-todo')
  })

  it('hides add button when there are 10 todos', () => {
    for (let i = 1; i <= 10; i++) {
      actions.setInputValue('new-todo', `Todo ${i}`)
      actions.clickButton('add-todo')
    }

    expects.expectMessage('You have enough todos for today.')
    expects.expectButtonVisible('delete-todo')
 })

Conclusion

To sum up, encapsulating expectations and actions in separate objects can help make integration tests more modular and easier to manage. By breaking down the test into smaller, more focused functions, we can make the code easier to read and understand. This approach can also make it easier to add new tests or modify existing ones as the application evolves over time.

Furthermore, by using integration tests, we can gain more confidence in the overall behavior of the application and ensure that different components work together as expected. This approach can help catch issues early on in the development cycle, leading to a more reliable and robust application.

Overall, by encapsulating expectations and actions in separate objects and using integration testing, we can create more effective and maintainable tests that help us build better applications.