State Management with Svelte - Props (Part 1)

Each component of a client-side application contains internal state that encapsulates its own data, which determines the component's behavior and stores business-related data for rendering. When composing many components into a multi-level hierarchy, components must communicate data and coordinate amongst each other to perform more complex tasks. For example, a 

 component might pass a list of search results to a 

 component to display suggestions based on the currently typed query. There are three common approaches to facilitate communication amongst the various components within a Svelte application: 

Having full control over state within an application allows developers to know how data flows throughout the application, better reason about the data and optimize accordingly. Modeling data flow with props, contexts and/or stores improves the organization of state, normalizes data to reduce instances of duplicated data and curtails the amount of time spent on debugging (quickly identify the component/s or portions of state responsible for a bug).

Below, and in two additional blog posts, I'm going to show you:

The simplest form of communication involves a parent component passing data to its direct child component/s via 

. This concept is widely adopted in other popular component-based libraries/frameworks, such as 

 keyword defines a prop that a component can accept from its consumers.

 from a higher-level component to a lower-level component in the component hierarchy. This means changes made to a prop in a child component will not propagate back to its parent component and yield any unwanted side effects. Unlike two-way data-binding in 

, which caused performance issues and modal updates to cascade, one-way data binding with props reduces the number of possible points of failure due to the predictable nature of component/application state.

If multiple props need to passed to a component, then consider packing all the props into an object and 

 them onto the component, which serves as a convenient shortcut for passing many props rather than individually specifying them.

If the parent component does not specify the prop on the child component, then its value will be set to 

 by default. However, instead of setting its value to 

, the prop can be set to a default initial value.

 allows those props to be modified within the component itself.

When clicking the button and incrementing the value of the prop 

, the newly incremented value is logged to the developers tool console, which indicates this prop being modified in the 

 component. However, this change is not propagated to the 

 tag remains zero no matter how many times you click on the "Increment" button.

 are not props, but instead, are readonly constants that can be imported into other components as named imports.

To export these variables for consumption in other components via an 

, which will execute the code within the 

 block once upon the evaluation of the module, not the instantiation of the component. 

 statements and then clicking on the button bound to the event handler containing this statement will result in an error being logged to the developers tool console and 

 not being incremented. Variables declared with 

 to a different value. This also applies to variables declared with 

 can be modified, but the reference to the object cannot be changed.

Suppose you decide to export a function that changes a value within the component it is exported from.

Clicking the "Increment" button will call the imported 

A function can be exported from an instance directly and accessed as a property on the component's reference, which can be obtained via the 

 directive. These properties are accessible after the component has been mounted to the DOM.

When clicking the "Increment" button, not only is 

 incremented, but its new value is displayed in the 

For grandchild components to receive data from grandparent components, that data must first be passed from the grandparent component to its child component (the grandchild's parent component), and then, that data must be passed from this parent component to its child component (the grandchild component). 

This process of explicitly and redundantly passing data from higher-level ancestor components to lower-level descendant components via props is known as 

. As the number of component layers increases, it becomes more difficult to track these props, especially when refactoring components and having to manually rename or remove props. In the above example, if we decide to rename the 

, then we would have to start renaming the prop at the 

 component and traverse down its subtree, renaming the prop at each subsequent component (the 

 prop whatsoever. It simply receives this prop and passes it directly to the 

 component. Having these types of props in our components can add unnecessary clutter to them and exacerbate our ability to understand and maintain these components.

Alternatively, to make data available to a component and its descendants without prop drilling, Svelte provides the 

 to learn more about Svelte's Context API.

If you want to learn more about Svelte, then check out 

AUTHOR

Ken Chan

Each component of a client-side application contains internal state that encapsulates its own data, which determines the component's behavior and stores business-related data for rendering. When composing many components into a multi-level hierarchy, components must communicate data and coordinate…

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Free Tools

State Management with Svelte - Props (Part 1)

Tags

Responses (0)

Free AI Career Tools

AI Job Listings

ATS Resume Checker

Startup Perks

Masterclasses

Tutorials

Fullstack React with TypeScript