Tag: Native


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
1-mounting-unmounting-navigation-routes-authentication-react-native
12 Aug

Handling Mounting And Unmounting Of Navigation Routes In React Native

by TBSCategories: News

In this article, we are going to walk through mounting and unmounting of navigation routes in React Native. An expected behavior of your app is that once the authentication condition is met, a new set of navigation routes are available only to logged-in users, while the other screens which were displayed before authentication is removed and can’t be returned to unless the user signs out of the application.

For security in your app, protected routes provide you with a way to only display certain information/content on your app to specific users, while restricting access from unauthorized persons.

We will be working with Expo for this project because it’ll help us focus on the problem at hand instead of worrying about a lot of setups. The exact same steps in this article could be followed for a bare React Native application.

You need some familiarity with JavaScript and React Native to follow through with this tutorial. Here are a few important things you should already be familiar with:

  • Custom components in React Native (how to create components, receive, pass, and use props in a component). Read more.
  • React Navigation. Read more.
  • Stack Navigator in React Native. Read more.
  • Basic Knowledge of React Native Core components (<View/>, <Text/>, etc.). Read more.
  • React Native AsyncStorage. Read more.
  • Context API. Read more.

Project Setup And Base Authentication

If you’re new to using expo and don’t know how to install expo, visit the official documentation. Once the installation is complete, go ahead to initialize a new React Native project with expo from our command prompt:

expo init navigation-project

You will be presented with some options to choose how you want the base setup to be:

In our case, let’s select the first option to set up our project as a blank document. Now, wait until the installation of the JavaScript dependencies is complete.

Once our app is set up, we can change our directory to our new project directory and open it in your favorite code editor. We need to install the library we will be using for AsyncStorage and our navigation libraries. Inside your folder directory in your terminal, paste the command above and choose a template (blank would work) to install our project dependencies.

Let’s look at what each of these dependencies is for:

  • @react-native-community/async-storage
    Like localStorage on the web, it is a React Native API for persisting data on a device in key-value pairs.
  • @react-native-community/masked-view, react-native-screens, react-native-gesture-handle
    These dependencies are core utilities that are used by most navigators to create the navigation structure in the app. (Read more in Getting started with React Native navigation.)
  • @react-navigation/native
    This is the dependency for React Native navigation.
  • @react-navigation/stack
    This is the dependency for stack navigation in React Native.
npm install @react-native-community/async-storage @react-native-community/masked-view @react-navigation/native @react-navigation/stack react-native-screens react-native-gesture-handle

To start the application use expo start from the app directory in your terminal. Once the app is started, you can use the expo app from your mobile phone to scan the bar code and view the application, or if you have an android emulator/IOS simulator, you can open the app through them from the expo developer tool that opens up in your browser when you start an expo application. For the images examples in this article, we will be using Genymotions to see our result. Here’s what our final result will look like in Genymotions:

Folder Structures

Let us create our folder structure from the start so that it’s easier for us to work with it as we proceed:

We need two folders first:

  • context
    This folder will hold the context for our entire application as we will be working with Context API for global state management.
  • views
    This folder will hold both the navigation folder and the views for different screens.

Go ahead and create the two folders in your project directory.

Inside the context folder, create a folder called authContext and create two file inside of the authContext folder:

  • AuthContext.js,
  • AuthState.js.

We will need these files when we start working with Context API.

Now go to the views folder we created and create two more folders inside of it, namely:

  • navigation,
  • screens.

Now, we are not yet finished, inside the screens folder, create these two more folders:

  • postAuthScreens,
  • preAuthScreens.

If you followed the folder setup correctly, this is how your folder structure should look like at the moment:

Creating Our First Screen

Now let’s create our first screen and call it the welcomeScreen.js inside the preAuthScreens folder.

preAuthScreens > welcomeScreen.js

Here’s the content of our welcomeScreen.js file:

import React from 'react'; import { View, Text, Button, StyleSheet, TextInput } from 'react-native';  const WelcomeScreen = () => {    const onUserAuthentication = () => {     console.log("User authentication button clicked")   }    return (     <View style={styles.container}>       <Text style={styles.header}>Welcome to our App!</Text>       <View>         <TextInput style={styles.inputs} placeholder="Enter your email here.." />         <TextInput style={styles.inputs} secureTextEntry={true} placeholder="Enter your password here.." /> <Button  title="AUTHENTICATE" onPress={onUserAuthentication} />       </View>     </View>   ) }  const styles = StyleSheet.create({   container: {     flex: 1,     backgroundColor: '#fff',     alignItems: 'center',     justifyContent: 'center',   },   header: {     fontSize: 25,     fontWeight: 'bold',     marginBottom: 30   },   inputs: {     width: 300,     height: 40,     marginBottom: 10,     borderWidth: 1,   } })  export default WelcomeScreen

Here’s what we did in the code block above:

First, we imported the things we need from the React Native library, namely, View, Text, Button, TextInput. Next, we created our functional component WelcomeScreen.

You’ll notice that we imported the StyleSheet from React Native and used it to define styles for our header and also our <TextInput />.

Lastly, we export the WelcomeScreen component at the bottom of the code.

Now that we are done with this, let’s get this component to function as expected by using the useState hook to store the values of the inputs and update their states anytime a change happens in the input fields. We will also bring import the useCallback hook from React as we will be needing it later to hold a function.

First, while we are still in the WelcomeScreen component, we need to import the useState and useCallback from React.

import React, { useState, useCallback } from 'react';

Now inside the WelcomeScreen functional component, let’s create the two states for the email and password respectively:

... const WelcomeScreen = () => {   const [email, setEmail] = useState('')   const [password, setPassword] = useState('')   return (     ...   ) } ...

Next, we need to modify our <TextInput /> fields so that the get their value from their respective states and update their state when the value of the input is updated:

import React, { useState, useCallback } from 'react'; import { View, Text, Button, StyleSheet, TextInput } from 'react-native';  const WelcomeScreen = () => {   const [email, setEmail] = useState('')   const [password, setPassword] = useState('')    const onInputChange = (value, setState) => {     setState(value);   }   return (     <View>       ...
      <View>         <TextInput           style={styles.inputs}           placeholder="Enter your email here.."           value={email}           onChangeText={(value) => onInputChange(value, setEmail)}         />         <TextInput           style={styles.inputs}           secureTextEntry={true}           placeholder="Enter your password here.."           value={password}           onChangeText={(value) => onInputChange(value, setPassword)}         />         ...       </View>     </View>   ) } ...

In the code above, here is what we did:

  • We made the value of each of the text inputs to point to their respective states.
  • We added the onChangeText handler to our text inputs. This fires up anytime a new value is entered or deleted from the input fields.
  • We called our onInputChange function which accepts two arguments:
    • The current value is supplied by the onChangeText handler.
    • The setter of the state that should be updated (for the first input field we pass setEmail and the second we pass setPassword.
    • Finally, we write our onInputChange function, and our function does only one thing: It updates the respective states with the new value.

The next thing we need to work on is the onUserAuthentication() function with is called whenever the button for the form submission is clicked.

Ideally, the user must have already created an account and login will involve some backend logic of some sort to check that the user exists and then assign a token to the user. In our case, since we are not using any backend, we will create an object holding the correct user login detail, and then only authenticate a user when the values they enter matches our fixed values from the login object of email and password that we will create.

Here’s the code we need to do this:

...  const correctAuthenticationDetails = {   email: 'demouser@gmail.com',   password: 'password' } const WelcomeScreen = () => {   ...    // This function gets called when the AUTHENTICATE button is clicked   const onUserAuthentication = () => {     if (       email !== correctAuthenticationDetails.email ||       password !== correctAuthenticationDetails.password     ) {       alert('The email or password is incorrect')       return     }       // In here, we will handle what happens if the login details are       // correct   }    ...   return (     ...   ) } ...

One of the first things you’ll notice in the code above is that we defined a correctAuthenticationDetails (which is an object that holds the correct login details we expect a user to supply) outside of the WelcomeScreen() functional component.

Next, we wrote the content of the onUserAuthentication() function and used a conditional statement to check if the email or password held in the respective states does not match the one we supplied in our object.

If you would like to see what we have done so far, import the WelcomeScreen component into your App.js like this:

Open the App.js file and put this replace the entire code with this:

import { StatusBar } from 'expo-status-bar'; import React from 'react'; import { View } from 'react-native'; import WelcomeScreen from './views/screens/preAuthScreens/welcomeScreen'; export default function App() {   return (     <View>       <StatusBar style="auto" />       <WelcomeScreen />     </View>   ); }

Looking closely at the code above, you’ll see that what we did was import the WelcomeScreen component and then used it in the App() function.

Here’s what the result looks like of our WelcomeScreen looks like:

Now that we are done building the WelcomeScreen component, let’s move ahead and start working with Context API for managing our global state.

Why Context API?

Using Context API, we do not need to install any additional library into ReactJS, it is less stressful to set up, and is one of the most popular ways of handling global state in ReactJS. For lightweight state management, it is a good choice.

Creating Our Context

If you recall, we created a context folder earlier and created a subfolder inside of it called the authContext.

Now let’s navigate to the AuthContext.js file in the authContext folder and create our context:

context > authContext > AuthContext.js

 import React, { createContext } from 'react'; const AuthContext = createContext(); export default AuthContext;

The AuthContext we just created holds the loading state value and the userToken state values. Currently, in the createContext we declared in the code-block above, we didn’t initialize any default values here so our context is currently undefined. An example value of the auth context could be {loading: false, userToken: 'abcd}

The AuthState.js file holds our Context API logic and their state values. Functions written here can be called from anywhere in our app and when they update values in state, it is updated globally also.

First, let’s bring in all the imports we will need in this file:

context > AuthContext > AuthState.js

import React, { useState } from 'react'; import AuthContext from './AuthContext'; import AsyncStorage from '@react-native-community/async-storage';

We imported the useState() hook from ReactJS to hold our states, we imported the AuthContext file we created above because this is where our empty context for authentication is initialized and we will need to use it as you’ll see later on while we progress, finally we import the AsyncStorage package (similar to localStorage for the web).

AsyncStorage is a React Native API that allows you to persist data offline over the device in a React Native application.

...  const AuthState = (props) => {     const [userToken, setUserToken] = useState(null);     const [isLoading, setIsLoading] = useState(true);      const onAuthentication = async() => {         const USER_TOKEN = "drix1123q2"         await AsyncStorage.setItem('user-token', USER_TOKEN);         setUserToken(USER_TOKEN);         console.warn("user has been authenticated!")     }      return (         <AuthContext.Provider             value={{                 onAuthentication,             }}         >             {props.children}         </AuthContext.Provider>     ) } export default AuthState;

In the code block above here’s what we did:

  • We declared two states for the userToken and isLoading. The userToken state will be used to store the token saved to AsyncStorage, while the isLoading state will be used to track the loading status (initially it is set to true). We will find out more about the use of these two states as we proceed.

  • Next, we wrote our onAuthentication() function. This function is an async function that gets called when the login button is clicked from the welcomeScreen.jsx file. This function will only get called if the email and password the user has supplied matches the correct user detail object we provided. Usually what happens during authentication is that a token is generated for the user after the user is authenticated on the backend using a package like JWT, and this token is sent to the frontend. Since we are not going into all of that for this tutorial, we created a static token and kept it in a variable called USER_TOKEN.

  • Next, we use the await keyword to set our user token to AsyncStorage with the name user-token. The console.warn() statement is just used to check that everything went right, you can take it off whenever you like.

  • Finally, we pass our onAuthenticated function as a value inside our <AuthContext.Provider> so that we can access and call the function from anywhere in our app.

screens > preAuth > welcomeScreen.js

First, import useContext from ReactJS and import the AuthContext from the AuthContext.js file.

import React, { useState, useContext } from 'react'; import AuthContext from '../../../context/authContext/AuthContext' ...

Now, inside the welcomeScreen() functional component, let’s use the context which we have created:

... const WelcomeScreen = () => {   const { onAuthentication } = useContext(AuthContext)   const onUserAuthentication = () => {     if (       email !== correctAuthenticationDetails.email ||       password !== correctAuthenticationDetails.password     ) {       alert('The email or password is incorrect')       return     }     onAuthentication()   }   return (     ...   ) } ...

In the above code block, we destructured the onAuthentication function from our AuthContext and then we called it inside our onUserAuthentication() function and removed the console.log() statement which was there before now.

Right now, this will throw an error because we don’t yet have access to the AuthContext. To use the AuthContext anywhere in your application, we need to wrap the top-level file in our app with the AuthState (in our case, it is the App.js file).

Go to the App.js file and replace the code there with this:

import React from 'react'; import WelcomeScreen from './views/screens/preAuthScreens/welcomeScreen'; import AuthState from './context/authContext/AuthState'  export default function App() {   return (     <AuthState>       <WelcomeScreen />     </AuthState>   ); }

We’ve come so far and we’re done with this section. Before we move into the next section where we set up our routing, let’s create a new screen. The screen we are about to create will be the HomeScreen.js file which is supposed to show up only after successful authentication.

Go to: screens > postAuth.

Create a new file called HomeScreen.js. Here’s the code for the HomeScreen.js file:

screens > postAuth > HomeScreen.js

import React from 'react'; import { View, Text, Button, StyleSheet } from 'react-native';  const HomeScreen = () => {    const onLogout = () => {     console.warn("Logout button cliked")   }    return (     <View style={styles.container}>       <Text>Now you're authenticated! Welcome!</Text>       <Button title="LOG OUT" onPress={onLogout} />     </View>   ) }  const styles = StyleSheet.create({   container: {     flex: 1,     backgroundColor: '#fff',     alignItems: 'center',     justifyContent: 'center',   }, })  export default HomeScreen

For now, the logout button has a dummy console.log() statement. Later on, we will create the logout functionality and pass it to the screen from our context.

Setting Up Our Routes

We need to create three (3) files inside our navigation folder:

  • postAuthNavigator.js,
  • preAuthNavigator.js,
  • AppNavigator.js.

Once you’ve created these three files, navigate to the preAuthNaviagtor.js file you just created and write this:

navigation > preAuthNavigator.js

import React from "react"; import { createStackNavigator } from "@react-navigation/stack"; import WelcomeScreen from "../screens/preAuthScreens/welcomeScreen";  const PreAuthNavigator = () => {     const { Navigator, Screen } = createStackNavigator();      return (         <Navigator initialRouteName="Welcome">             <Screen                 name="Welcome"                 component={WelcomeScreen}             />         </Navigator>     ) } export default PreAuthNavigator;

In the file above, here’s what we did:

  • We imported the createStackNavigator from the @react-navigation/stack which we are using for our stack navigation. The createStackNavigatorProvides a way for your app to transition between screens where each new screen is placed on top of a stack. By default the stack navigator is configured to have the familiar iOS and Android look & feel: new screens slide in from the right on iOS, fade in from the bottom on Android. Click here if you want to learn more about the stack navigator in React Native.
  • We destructured Navigator and Screen from the createStackNavigator().
  • In our return statement, we created our navigation with the <Navigator/> and created our screen with the <Screen/>. this means that if we had multiple screens that can be accessed before authentication, we will have multiple <Screen/> tags here representing them.
  • Finally, we export our PreAuthNavigator component.

Let us do a similar thing for the postAuthNavigator.js file.

navigation > postAuthNavigator.js

import React from "react"; import { createStackNavigator } from "@react-navigation/stack"; import HomeScreen from "../screens/postAuthScreens/HomeScreen"; const PostAuthNavigator = () => {   const { Navigator, Screen} = createStackNavigator();   return (     <Navigator initialRouteName="Home">       <Screen         name="Home"         component={HomeScreen}       />     </Navigator>    ) } export default PostAuthNavigator;

As we see in the code above, the only difference between the preAuthNavigator.js and the postAuthNavigator.js is the screen being rendered. While the first one takes the WelcomeScreen, the postAuthNavigator.js takes the HomeScreen.

To create our AppNavigator.js we need to create a few things.

Since the AppNavigator.js is where we will be switching and checking which route will be available for access by the user, we need several screens in place for this to work properly, let’s outline the things we need to create first:

  1. TransitionScreen.js
    While the app decides which navigation it is going to mount, we want a transition screen to show up. Typically, the transition screen will be a loading spinner or any other custom animation chosen for the app, but in our case, we will use a basic <Text/> tag to display loading….
  2. checkAuthenticationStatus()
    This function is what we will be calling to check the authentication status which will determine which navigation stack is going to be mounted. We will create this function in our context and use it in the Appnavigator.js.

Now, let’s go ahead and create our TransitionScreen.js file.

screens > TransitionScreen.js

import React from 'react'; import { Text, View } from 'react-native';  const TransitionScreen = () => {   return (     <View>       <Text>Loading...</Text>     </View>   ) }  export default TransitionScreen

Our transition screen is just a simple screen that shows loading text. We will see where to use this as we proceed in this article.

Next, let us go to our AuthState.js and write our checkAuthenticationStatus():

context > authContext > AuthState.js

import React, { useState, useEffect } from 'react'; import AuthContext from './AuthContext'; import AsyncStorage from '@react-native-community/async-storage';  const AuthState = (props) => {     const [userToken, setUserToken] = useState(null);     const [isLoading, setIsLoading] = useState(true);      ...     useEffect(() => {         checkAuthenticationStatus()     }, [])      const checkAuthenticationStatus = async () => {         try {             const returnedToken = await AsyncStorage.getItem('user-toke             n');             setUserToken(returnedToken);             console.warn('User token set to the state value)         } catch(err){             console.warn(Here's the error that occured while retrievin             g token: $ {err})          }         setIsLoading(false)     }       const onAuthentication = async() => {         ...     }      return (         <AuthContext.Provider             value={{                 onAuthentication,                 userToken,                 isLoading,             }}         >             {props.children}         </AuthContext.Provider>     ) } export default AuthState;

In the code block above, we wrote the function checkAuthenticationStatus(). In our function, here’s what we are doing:

  • We used the await keyword to get our token from AsyncStorage. With AsyncStorage, if there’s no token supplied, it returns null. Our initial userToken state is set to null also.
  • We use the setUserToken to set our returned value from AsyncStorage as our new userToken. If the returned value is null, it means our userToken remains null.
  • After the try{}…catch(){} block, we set isLoading to false because the function to check authentication status is complete. We’ll need the value of isLoading to know if we should still be displaying the TransitionScreen or not. It’s worth considering setting an error if there is an error retrieving the token so that we can show the user a “Retry” or “Try Again” button when the error is encountered.
  • Whenever AuthState mounts we want to check the authentication status, so we use the useEffect() ReactJS hook to do this. We call our checkAuthenticationStatus() function inside the useEffect() hook and set the value of isLoading to false when it is done.
  • Finally, we add our states to our <AuthContext.Provider/> values so that we can access them from anywhere in our app covered by the Context API.

Now that we have our function, it is time to go back to our AppNavigator.js and write the code for mounting a particular stack navigator based on the authentication status:

navigation > AppNavigator.js

First, we will import all we need for our AppNavigator.js.

import React, { useEffect, useContext } from "react"; import PreAuthNavigator from "./preAuthNavigator"; import PostAuthNavigator from "./postAuthNavigator"; import { NavigationContainer } from "@react-navigation/native" import { createStackNavigator } from "@react-navigation/stack"; import AuthContext from "../../context/authContext/AuthContext"; import TransitionScreen from "../screens/TransitionScreen";

Now that we have all our imports, let’s create the AppNavigator() function.

... const AppNavigator = () => {  }  export default AppNavigator

Next, we will now go ahead to write the content of our AppNavigator() function:

import React, { useState, useEffect, useContext } from "react"; import PreAuthNavigator from "./preAuthNavigator"; import PostAuthNavigator from "./postAuthNavigator"; import { NavigationContainer } from "@react-navigation/native" import { createStackNavigator } from "@react-navigation/stack"; import AuthContext from "../../context/authContext/AuthContext"; import TransitionScreen from "../screens/transition";  const AppNavigator = () => {     const { Navigator, Screen } = createStackNavigator();     const authContext = useContext(AuthContext);     const { userToken, isLoading } = authContext;     if(isLoading) {       return <TransitionScreen />     }     return (     <NavigationContainer>       <Navigator>         {            userToken == null ? (             <Screen               name="PreAuth"               component={PreAuthNavigator}               options={{ header: () => null }}             />           ) : (             <Screen                name="PostAuth"               component={PostAuthNavigator}               options={{ header: () => null }}             />           )         }       </Navigator>     </NavigationContainer>   ) }  export default AppNavigator

In the above block of code, here’s an outline of what we did:

  • We created a stack navigator and destructured the Navigator and Screen from it.
  • We imported the userToken and the isLoading from our AuthContext
  • When the AuthState mounts, the checkAuthenticationStatus() is called in the useEffecct hook there. We use the if statement to check if isLoading is true, if it is true the screen we return is our <TransitionScreen /> which we created earlier because the checkAuthenticationStatus() function is not yet complete.
  • Once our checkAuthenticationStatus() is complete, isLoading is set to false and we return our main Navigation components.
  • The NavigationContainer was imported from the @react-navigation/native. It is only used once in the main top-level navigator. Notice that we are not using this in the preAuthNavigator.js or the postAuthNavigator.js.
  • In our AppNavigator(), we still create a stack navigator. If the userToken gotten from our Context API is null, we mount the PreAuthNavigator, if its value is something else (meaning that the AsyncStorage.getItem() in the checkAuthenticationStatus() returned an actual value), then we mount the PostAuthNavigator. Our conditional rendering is done using the ternary operator.

Now we’ve set up our AppNavigator.js. Next, we need to pass our AppNavigator into our App.js file.

Let’s pass our AppNavigator into the App.js file:

App.js

 ... import AppNavigator from './views/navigation/AppNavigator';  ... return (     <AuthState>       <AppNavigator />     </AuthState>   );

Let’s now see what our app looks like at the moment:

Here’s what happens when you supply an incorrect credential while trying to log in:

Adding The Logout Functionality

At this point, our authentication and route selection process is complete. The only thing left for our app is to add the logout functionality.

The logout button is in the HomeScreen.js file. We passed an onLogout() function to the onPress attribute of the button. For now, we have a simple console.log() statement in our function, but in a little while that will change.

Now, let’s go to our AuthState.js and write the function for logout. This function simply clears the AsyncStorage where the user token is saved.

context > authContext > AuthState.js

... const AuthState = (props) => {     ...      const userSignout = async() => {         await AsyncStorage.removeItem('user-token');         setUserToken(null);     }       return (       ...     ) }  export default AuthState;

The userSignout() is an asynchronous function that removes the user-token from our AsyncStorage.

Now we need to call the userSignout() function in our HomeScreen.js any time the logout button is clicked on.

Let’s go to our HomeScreen.js and use ther userSignout() from our AuthContext.

screens > postAuthScreens > HomeScreen.js

import React, { useContext } from 'react'; import { View, Text, Button, StyleSheet } from 'react-native'; import AuthContext from '../../../context/authContext/AuthContext'  const HomeScreen = () => {   const { userSignout } = useContext(AuthContext)    const onLogout = () => {     userSignout()   }   return (     <View style={styles.container}>       <Text>Now you're authenticated! Welcome!</Text>  <Button title="LOG OUT" onPress={onLogout} />     </View>   ) } ...

In the above code block we imported thee useContext hook from ReactJS, then we imported our AuthContext. Next, we destructured the userSignout function from our AuthContext and this userSignout() function is called in our onLogout() function.

Now whenever our logout button is clicked, the user token in our AsyncStorage is cleared.

Voila! our entire process is finished.

Here’s what happens when you press the back button after you’re logged in:

Here’s what happens when you press the back button after logging out:

Here are some different behaviors we notice when using this pattern in our navigation stack switching:

  1. You’ll notice that there was nowhere we needed to make use of navigation.navigate() or navigation.push() to go to another route after login. Once our state is updated with the user token, the navigation stack rendered is automatically changed.
  2. Pressing the back button on your device after login is successful cannot take you back to the login page, instead, it closes the app entirely. This behavior is important because you don’t want the user to be able to return back to the login page except they log out of the app. The same thing applies to logging out — once the user logs out, they cannot use the back button to return to the HomeScreen screen, but instead, the app closes.

Conclusion

In many Apps, authentication is one of the most important parts because it confirms that the person trying to gain access to protected content has the right to access the information. Learning how to do it right is an important step in building a great, intuitive, and easy to use/navigate the application.

Building on top of this code, here are a few things you might consider adding:

Here are also some important resources I found that will enlighten you more about authentication, security and how to do it right:

Resources

Articles on Smashing Magazine — For Web Designers And Developers

10 Jun

Meet :has, A Native CSS Parent Selector (And More)

by TBSCategories: News

Parent selector has been on developers’ wishlist for more than 10 years and it has become one of the most requested CSS features alongside container queries ever since. The main reason this feature wasn’t implemented all this time seems to be due to performance concerns. The same was being said about the container queries and those are currently being added to beta versions of browsers, so those performance seems to be no longer an issue.

Browser render engines have improved quite a bit since then. The rendering process has been optimized to the point that browsers can effectively determine what needs to be rendered or updated and what doesn’t, opening the way for a new and exciting set of features.

Brian Kardell has recently announced that his team at Igalia is currently prototyping a :has selector that will serve as a parent selector, but it could have a much wider range of use-cases beyond it. The developer community refers to it as a “parent selector” and some developers have pointed out that the name isn’t very accurate. A more fitting name would be a relational selector or relational pseudo-class as per specification, so I’ll be referring to :has as such from now on in the article.

The team at Igalia has worked on some notable web engine features like CSS grid and container queries, so there is a chance for :has selector to see the light of day, but there is still a long way to go.

What makes relational selector one of the most requested features in the past few years and how are the developers working around the missing selector? In this article, we’re going to answer those questions and check out the early spec of :has selector and see how it should improve the styling workflow once it’s released.

Potential Use-Cases

The relational selector would be useful for conditionally applying styles to UI components based on the content or state of its children or its succeeding elements in a DOM tree. Upcoming relational selector prototype could extend the range and use-cases for existing selectors, improve the quality and robustness of CSS and reduce the need for using JavaScript to apply styles and CSS classes for those use-cases.

Let’s take a look at a few specific examples to help us illustrate the variety of potential use-cases.

Content-Based Variations

Some UI elements can have multiple variations based on various aspects — content, location on the page, child state, etc. In those cases, we usually create multiple CSS classes to cover all the possible variations and apply them manually or with JavaScript, depending on the approach and tech stack.

Even when using CSS naming methodology like BEM, developers need to keep track of the various CSS classes and make sure to apply them correctly to the parent element and, optionally, to affected child elements. Depending on the number of variations, component styles can get out of hand quickly and become difficult to manage and maintain leading to bugs, so developers would need to document all variations and use-cases by using tools like Storybook.

With a relational CSS selector, developers would be able to write content checks directly in CSS and styles would be applied automatically. This would reduce the amount of variation CSS classes, decrease the possibility of bugs caused by human error, and selectors would be self-documented with the condition checks.

Validation-Based Styles

CSS supports input pseudo-classes like :valid and :invalid to target elements that successfully validate and elements that unsuccessfully validate, respectfully. Combined with HTML input attributes like pattern and required, it enables native form validation without the need to rely on JavaScript.

However, targeting elements with :valid and :invalid is limited to targeting the element itself or its adjacent element. Depending on the design and HTML structure, input container elements or preceding elements like label elements also need some style to be applied.

The relational selector would extend the use-case for the input state pseudo-classes like :valid and :invalid by allowing the parent element or preceding elements to be styled based on the input validity.

This doesn’t apply only to those pseudo-classes. When working with an external API that returns error messages that are appended in the input container, there won’t be a need to also apply the appropriate CSS class to the container. By writing a relational selector with a condition that checks if the child message container is empty, appropriate styles can be applied to the container.

Children Element State

Sometimes a parent element or preceding element styles depend on the state of a target element. This case is different from the validation state because the state isn’t closely related to the validity of the input.

Just like in the previous example, :checked pseudo-class for checkbox and radio input elements is limited to targeting the element itself or its adjacent element. This is not limited to pseudo-classes like :checked, :disabled, :hover, :visited, etc. but to anything else that CSS selectors can target like the availability of specific element, attribute, CSS class, id, etc.

Relation selectors would extend the range and use-cases of CSS selectors beyond the affected element or its adjacent element.

Selecting Previous Siblings

CSS selectors are limited by the selection direction — child descendant or following element can be selected, but not the parent or preceding element.

A relational selector could also be used as a previous sibling selector.

Advanced :empty Selector

When working with dynamically loaded elements and using skeleton loaders, it’s common to toggle a loading CSS class on the parent element with JavaScript once the data is fetched and components are populated with data.

Relational selector could eliminate the need for JavaScript CSS class toggle function by extending the range and functionality of :empty pseudo-class. With relational selector, necessary conditions to display an element can be defined in CSS by targeting required data HTML elements and checking if it’s populated with data. This approach should work with deeply nested and complex elements.

CSS :has Pseudo-Class Specification

Keep in mind that :has is not supported in any browsers so the code snippets related to the upcoming pseudo-class won’t work. Relational pseudo-class is defined in selectors level 4 specification which has been updated since its initial release in 2011, so the specification is already well-defined and ready for prototyping and development.

That being said, let’s dive into the :has pseudo-class specification. The idea behind the pseudo-class is to apply styles to a selector if the condition (defined as a regular CSS selector) has been met.

/* Select figure elements that have a figcaption as a child element */ figure:has(figcaption) { /* ... */ }  / Select button elements that have an element with .icon class as a child */ button:has(.icon) { /* ... */ }  / Select article elements that have a h2 element followed by a paragraph element */ article:has(h2 + p) { /* ... */ }

Similar to the other pseudo-classes like :not, relational pseudo selector consists of the following parts.

<target_element>:has(<selector>) { /* ... */ }
  • <target_element>
    Selector for an element that will be targeted if condition passed as an argument to :has pseudo-class has been met. Condition selector is scoped to this element.
  • <selector>
    A condition defined with a CSS selector that needs to be met for styles to be applied to the selector.

Like with most pseudo-classes, selectors can be chained to target child elements of a target element or adjacent element.

/* Select image element that is a child of a figure element if figure element has a figcaption as a child */ figure:has(figcaption) img { /* ... */ }  /* Select a button element that is a child of a form element if a child checkbox input element is checked */ form:has(input[type="checkbox"]:checked) button { /* ... */ }

From these few examples, it is obvious how versatile, powerful and useful the :has pseudo-class is. It can even be combined with other pseudo-classes like :not to create complex relational selectors.

/* Select card elements that do not have empty elements */ .card:not(:has(*:empty)) { /* ... */ }  /* Select form element that where at least one checkbox input is not checked */ form:has(input[type="checkbox"]:not(:checked)) { /* ... */ }

The relational selector is not limited to the target element’s children content and state, but can also target adjacent elements in the DOM tree, effectively making it a “previous sibling selector”.

/* Select paragraph elements which is followed by an image element */ p:has(+img) { /* ... */ }  /* Select image elements which is followed by figcaption element that doesn't have a "hidden" class applied */ img:has(~figcaption:not(.hidden)) { /* ... */ }  /* Select label elements which are followed by an input element that is not in focus */ label:has(~input:not(:focus)) { /* ... */ }

In a nutshell, relational selector anchors the CSS selection to an element with :has pseudo-class and prevents selection to move to the elements that are passed as an argument to the pseudo-class.

.card .title .icon -> .icon element is selected .card:has(.title .icon) -> .card element is selected  .image + .caption -> .caption element is selected .image:has(+.caption) -> .image element is selected

Current Approach And Workarounds

Developers currently have to use various workarounds to compensate for the missing relational selector. Regardless of the workarounds and as discussed in this article, it’s evident how impactful and game-changing the relational selector would be once released.

In this article, we’ll cover two most-used approaches when dealing with the use-cases where relational selector would be ideal:

  • CSS variation classes.
  • JavaScript solution and jQuery implementation of :has pseudo-class.

CSS Variation Classes For Static Elements

With CSS variation classes (modifier classes in BEM), developers can manually assign an appropriate CSS class to elements based on the element’s content. This approach works for static elements whose contents or state won’t change after the initial render.

Let’s take a look at the following card component example which has several variations depending on the content. Some cards don’t have an image, others don’t have a description and one card has a caption on the image.

See the Pen Card variations by Adrian Bece.

For these cards to have the correct layout, developers need to apply the correct modifier CSS classes manually. Based on the design, elements can have multiple variations resulting in a large number of modifier classes which sometimes leads to creative HTML workarounds to group all those classes in the markup. Developers need to keep track of the CSS classes, maintain documentation and make sure to apply appropriate classes.

.card { /* ... */} .card--news { /* ... */ } .card--text { /* ... */ } .card--featured { /* ... */ }  .card__title { /* ... */ } .card__title--news { /* ... */ } .card__title--text { /* ... */ }  /* ... */

JavaScript Workaround

For more complex cases, when the applied parent element style depends on child state or element content that changes dynamically, developers use JavaScript to apply necessary styles to the parent element depending on the changes in the content or state. This is usually handled by writing a custom solution on a case-by-case basis.

See the Pen Filter button state by Adrian Bece.

Relational Selector In jQuery

Implementation of relational :has selector has existed in popular JavaScript library jQuery since 2007 and it follows the CSS specification. Of course, the main limitation of this implementation is that the jQuery line needs to be manually attached invoked inside an event listener, whereas native CSS implementation would be a part of the browser render process and automatically respond to the page state and content changes.

The downside of the JavaScript and jQuery approach is, of course, reliance on JavaScript and jQuery library dependency which can increase the overall page size and JavaScript parsing time. Also, users that are browsing the Web with JavaScript turned off will experience visual bugs if fallback is not implemented.

// This runs only on initial render $  ("button:has(+.filters input:checked)").addClass("button--active");  // This runs each time input is clicked $  ("input").click(function() {   $  ("button").removeClass("highlight");   $  ("button:has(+.filters input:checked)").addClass("highlight"); })

See the Pen Email inputs — valid / invalid by Adrian Bece.

Conclusion

Similar to the container queries, :has pseudo-class will be a major game-changer when implemented in browsers. The relational selector will allow developers to write powerful and versatile selectors that are not currently possible with CSS.

Today, developers are dealing with the missing parent selector functionality by writing multiple modifier CSS classes that needed to be applied manually or with JavaScript, if the selector depends on a child element state. The relational selector should reduce the amount of modifier CSS classes by allowing developers to write self-documented robust selectors, and should reduce the need for JavaScript to apply dynamic styles.

Can you think of more examples where parent selector or previous sibling selector would be useful? Are you using a different workaround to deal with the missing relational selector? Share your thoughts with us in the comments.

References

Articles on Smashing Magazine — For Web Designers And Developers

10 Jun

Meet :has, A Native CSS Parent Selector (And More)

by TBSCategories: News

Parent selector has been on developers’ wishlist for more than 10 years and it has become one of the most requested CSS features alongside container queries ever since. The main reason this feature wasn’t implemented all this time seems to be due to performance concerns. The same was being said about the container queries and those are currently being added to beta versions of browsers, so those performance seems to be no longer an issue.

Browser render engines have improved quite a bit since then. The rendering process has been optimized to the point that browsers can effectively determine what needs to be rendered or updated and what doesn’t, opening the way for a new and exciting set of features.

Brian Kardell has recently announced that his team at Igalia is currently prototyping a :has selector that will serve as a parent selector, but it could have a much wider range of use-cases beyond it. The developer community refers to it as a “parent selector” and some developers have pointed out that the name isn’t very accurate. A more fitting name would be a relational selector or relational pseudo-class as per specification, so I’ll be referring to :has as such from now on in the article.

The team at Igalia has worked on some notable web engine features like CSS grid and container queries, so there is a chance for :has selector to see the light of day, but there is still a long way to go.

What makes relational selector one of the most requested features in the past few years and how are the developers working around the missing selector? In this article, we’re going to answer those questions and check out the early spec of :has selector and see how it should improve the styling workflow once it’s released.

Potential Use-Cases

The relational selector would be useful for conditionally applying styles to UI components based on the content or state of its children or its succeeding elements in a DOM tree. Upcoming relational selector prototype could extend the range and use-cases for existing selectors, improve the quality and robustness of CSS and reduce the need for using JavaScript to apply styles and CSS classes for those use-cases.

Let’s take a look at a few specific examples to help us illustrate the variety of potential use-cases.

Content-Based Variations

Some UI elements can have multiple variations based on various aspects — content, location on the page, child state, etc. In those cases, we usually create multiple CSS classes to cover all the possible variations and apply them manually or with JavaScript, depending on the approach and tech stack.

Even when using CSS naming methodology like BEM, developers need to keep track of the various CSS classes and make sure to apply them correctly to the parent element and, optionally, to affected child elements. Depending on the number of variations, component styles can get out of hand quickly and become difficult to manage and maintain leading to bugs, so developers would need to document all variations and use-cases by using tools like Storybook.

With a relational CSS selector, developers would be able to write content checks directly in CSS and styles would be applied automatically. This would reduce the amount of variation CSS classes, decrease the possibility of bugs caused by human error, and selectors would be self-documented with the condition checks.

Validation-Based Styles

CSS supports input pseudo-classes like :valid and :invalid to target elements that successfully validate and elements that unsuccessfully validate, respectfully. Combined with HTML input attributes like pattern and required, it enables native form validation without the need to rely on JavaScript.

However, targeting elements with :valid and :invalid is limited to targeting the element itself or its adjacent element. Depending on the design and HTML structure, input container elements or preceding elements like label elements also need some style to be applied.

The relational selector would extend the use-case for the input state pseudo-classes like :valid and :invalid by allowing the parent element or preceding elements to be styled based on the input validity.

This doesn’t apply only to those pseudo-classes. When working with an external API that returns error messages that are appended in the input container, there won’t be a need to also apply the appropriate CSS class to the container. By writing a relational selector with a condition that checks if the child message container is empty, appropriate styles can be applied to the container.

Children Element State

Sometimes a parent element or preceding element styles depend on the state of a target element. This case is different from the validation state because the state isn’t closely related to the validity of the input.

Just like in the previous example, :checked pseudo-class for checkbox and radio input elements is limited to targeting the element itself or its adjacent element. This is not limited to pseudo-classes like :checked, :disabled, :hover, :visited, etc. but to anything else that CSS selectors can target like the availability of specific element, attribute, CSS class, id, etc.

Relation selectors would extend the range and use-cases of CSS selectors beyond the affected element or its adjacent element.

Selecting Previous Siblings

CSS selectors are limited by the selection direction — child descendant or following element can be selected, but not the parent or preceding element.

A relational selector could also be used as a previous sibling selector.

Advanced :empty Selector

When working with dynamically loaded elements and using skeleton loaders, it’s common to toggle a loading CSS class on the parent element with JavaScript once the data is fetched and components are populated with data.

Relational selector could eliminate the need for JavaScript CSS class toggle function by extending the range and functionality of :empty pseudo-class. With relational selector, necessary conditions to display an element can be defined in CSS by targeting required data HTML elements and checking if it’s populated with data. This approach should work with deeply nested and complex elements.

CSS :has Pseudo-Class Specification

Keep in mind that :has is not supported in any browsers so the code snippets related to the upcoming pseudo-class won’t work. Relational pseudo-class is defined in selectors level 4 specification which has been updated since its initial release in 2011, so the specification is already well-defined and ready for prototyping and development.

That being said, let’s dive into the :has pseudo-class specification. The idea behind the pseudo-class is to apply styles to a selector if the condition (defined as a regular CSS selector) has been met.

/* Select figure elements that have a figcaption as a child element */ figure:has(figcaption) { /* ... */ }  / Select button elements that have an element with .icon class as a child */ button:has(.icon) { /* ... */ }  / Select article elements that have a h2 element followed by a paragraph element */ article:has(h2 + p) { /* ... */ }

Similar to the other pseudo-classes like :not, relational pseudo selector consists of the following parts.

<target_element>:has(<selector>) { /* ... */ }
  • <target_element>
    Selector for an element that will be targeted if condition passed as an argument to :has pseudo-class has been met. Condition selector is scoped to this element.
  • <selector>
    A condition defined with a CSS selector that needs to be met for styles to be applied to the selector.

Like with most pseudo-classes, selectors can be chained to target child elements of a target element or adjacent element.

/* Select image element that is a child of a figure element if figure element has a figcaption as a child */ figure:has(figcaption) img { /* ... */ }  /* Select a button element that is a child of a form element if a child checkbox input element is checked */ form:has(input[type="checkbox"]:checked) button { /* ... */ }

From these few examples, it is obvious how versatile, powerful and useful the :has pseudo-class is. It can even be combined with other pseudo-classes like :not to create complex relational selectors.

/* Select card elements that do not have empty elements */ .card:not(:has(*:empty)) { /* ... */ }  /* Select form element that where at least one checkbox input is not checked */ form:has(input[type="checkbox"]:not(:checked)) { /* ... */ }

The relational selector is not limited to the target element’s children content and state, but can also target adjacent elements in the DOM tree, effectively making it a “previous sibling selector”.

/* Select paragraph elements which is followed by an image element */ p:has(+img) { /* ... */ }  /* Select image elements which is followed by figcaption element that doesn't have a "hidden" class applied */ img:has(~figcaption:not(.hidden)) { /* ... */ }  /* Select label elements which are followed by an input element that is not in focus */ label:has(~input:not(:focus)) { /* ... */ }

In a nutshell, relational selector anchors the CSS selection to an element with :has pseudo-class and prevents selection to move to the elements that are passed as an argument to the pseudo-class.

.card .title .icon -> .icon element is selected .card:has(.title .icon) -> .card element is selected  .image + .caption -> .caption element is selected .image:has(+.caption) -> .image element is selected

Current Approach And Workarounds

Developers currently have to use various workarounds to compensate for the missing relational selector. Regardless of the workarounds and as discussed in this article, it’s evident how impactful and game-changing the relational selector would be once released.

In this article, we’ll cover two most-used approaches when dealing with the use-cases where relational selector would be ideal:

  • CSS variation classes.
  • JavaScript solution and jQuery implementation of :has pseudo-class.

CSS Variation Classes For Static Elements

With CSS variation classes (modifier classes in BEM), developers can manually assign an appropriate CSS class to elements based on the element’s content. This approach works for static elements whose contents or state won’t change after the initial render.

Let’s take a look at the following card component example which has several variations depending on the content. Some cards don’t have an image, others don’t have a description and one card has a caption on the image.

See the Pen Card variations by Adrian Bece.

For these cards to have the correct layout, developers need to apply the correct modifier CSS classes manually. Based on the design, elements can have multiple variations resulting in a large number of modifier classes which sometimes leads to creative HTML workarounds to group all those classes in the markup. Developers need to keep track of the CSS classes, maintain documentation and make sure to apply appropriate classes.

.card { /* ... */} .card--news { /* ... */ } .card--text { /* ... */ } .card--featured { /* ... */ }  .card__title { /* ... */ } .card__title--news { /* ... */ } .card__title--text { /* ... */ }  /* ... */

JavaScript Workaround

For more complex cases, when the applied parent element style depends on child state or element content that changes dynamically, developers use JavaScript to apply necessary styles to the parent element depending on the changes in the content or state. This is usually handled by writing a custom solution on a case-by-case basis.

See the Pen Filter button state by Adrian Bece.

Relational Selector In jQuery

Implementation of relational :has selector has existed in popular JavaScript library jQuery since 2007 and it follows the CSS specification. Of course, the main limitation of this implementation is that the jQuery line needs to be manually attached invoked inside an event listener, whereas native CSS implementation would be a part of the browser render process and automatically respond to the page state and content changes.

The downside of the JavaScript and jQuery approach is, of course, reliance on JavaScript and jQuery library dependency which can increase the overall page size and JavaScript parsing time. Also, users that are browsing the Web with JavaScript turned off will experience visual bugs if fallback is not implemented.

// This runs only on initial render $  ("button:has(+.filters input:checked)").addClass("button--active");  // This runs each time input is clicked $  ("input").click(function() {   $  ("button").removeClass("highlight");   $  ("button:has(+.filters input:checked)").addClass("highlight"); })

See the Pen Email inputs — valid / invalid by Adrian Bece.

Conclusion

Similar to the container queries, :has pseudo-class will be a major game-changer when implemented in browsers. The relational selector will allow developers to write powerful and versatile selectors that are not currently possible with CSS.

Today, developers are dealing with the missing parent selector functionality by writing multiple modifier CSS classes that needed to be applied manually or with JavaScript, if the selector depends on a child element state. The relational selector should reduce the amount of modifier CSS classes by allowing developers to write self-documented robust selectors, and should reduce the need for JavaScript to apply dynamic styles.

Can you think of more examples where parent selector or previous sibling selector would be useful? Are you using a different workaround to deal with the missing relational selector? Share your thoughts with us in the comments.

References

Articles on Smashing Magazine — For Web Designers And Developers

09 Jun

Meet :has, A Native CSS Parent Selector (And More)

by TBSCategories: News

Parent selector has been on developers’ wishlist for more than 10 years and it has become one of the most requested CSS features alongside container queries ever since. The main reason this feature wasn’t implemented all this time seems to be due to performance concerns. The same was being said about the container queries and those are currently being added to beta versions of browsers, so those performance seems to be no longer an issue.

Browser render engines have improved quite a bit since then. The rendering process has been optimized to the point that browsers can effectively determine what needs to be rendered or updated and what doesn’t, opening the way for a new and exciting set of features.

Brian Kardell has recently announced that his team at Igalia is currently prototyping a :has selector that will serve as a parent selector, but it could have a much wider range of use-cases beyond it. The developer community refers to it as a “parent selector” and some developers have pointed out that the name isn’t very accurate. A more fitting name would be a relational selector or relational pseudo-class as per specification, so I’ll be referring to :has as such from now on in the article.

The team at Igalia has worked on some notable web engine features like CSS grid and container queries, so there is a chance for :has selector to see the light of day, but there is still a long way to go.

What makes relational selector one of the most requested features in the past few years and how are the developers working around the missing selector? In this article, we’re going to answer those questions and check out the early spec of :has selector and see how it should improve the styling workflow once it’s released.

Potential Use-Cases

The relational selector would be useful for conditionally applying styles to UI components based on the content or state of its children or its succeeding elements in a DOM tree. Upcoming relational selector prototype could extend the range and use-cases for existing selectors, improve the quality and robustness of CSS and reduce the need for using JavaScript to apply styles and CSS classes for those use-cases.

Let’s take a look at a few specific examples to help us illustrate the variety of potential use-cases.

Content-Based Variations

Some UI elements can have multiple variations based on various aspects — content, location on the page, child state, etc. In those cases, we usually create multiple CSS classes to cover all the possible variations and apply them manually or with JavaScript, depending on the approach and tech stack.

Even when using CSS naming methodology like BEM, developers need to keep track of the various CSS classes and make sure to apply them correctly to the parent element and, optionally, to affected child elements. Depending on the number of variations, component styles can get out of hand quickly and become difficult to manage and maintain leading to bugs, so developers would need to document all variations and use-cases by using tools like Storybook.

With a relational CSS selector, developers would be able to write content checks directly in CSS and styles would be applied automatically. This would reduce the amount of variation CSS classes, decrease the possibility of bugs caused by human error, and selectors would be self-documented with the condition checks.

Validation-Based Styles

CSS supports input pseudo-classes like :valid and :invalid to target elements that successfully validate and elements that unsuccessfully validate, respectfully. Combined with HTML input attributes like pattern and required, it enables native form validation without the need to rely on JavaScript.

However, targeting elements with :valid and :invalid is limited to targeting the element itself or its adjacent element. Depending on the design and HTML structure, input container elements or preceding elements like label elements also need some style to be applied.

The relational selector would extend the use-case for the input state pseudo-classes like :valid and :invalid by allowing the parent element or preceding elements to be styled based on the input validity.

This doesn’t apply only to those pseudo-classes. When working with an external API that returns error messages that are appended in the input container, there won’t be a need to also apply the appropriate CSS class to the container. By writing a relational selector with a condition that checks if the child message container is empty, appropriate styles can be applied to the container.

Children Element State

Sometimes a parent element or preceding element styles depend on the state of a target element. This case is different from the validation state because the state isn’t closely related to the validity of the input.

Just like in the previous example, :checked pseudo-class for checkbox and radio input elements is limited to targeting the element itself or its adjacent element. This is not limited to pseudo-classes like :checked, :disabled, :hover, :visited, etc. but to anything else that CSS selectors can target like the availability of specific element, attribute, CSS class, id, etc.

Relation selectors would extend the range and use-cases of CSS selectors beyond the affected element or its adjacent element.

Selecting Previous Siblings

CSS selectors are limited by the selection direction — child descendant or following element can be selected, but not the parent or preceding element.

A relational selector could also be used as a previous sibling selector.

Advanced :empty Selector

When working with dynamically loaded elements and using skeleton loaders, it’s common to toggle a loading CSS class on the parent element with JavaScript once the data is fetched and components are populated with data.

Relational selector could eliminate the need for JavaScript CSS class toggle function by extending the range and functionality of :empty pseudo-class. With relational selector, necessary conditions to display an element can be defined in CSS by targeting required data HTML elements and checking if it’s populated with data. This approach should work with deeply nested and complex elements.

CSS :has Pseudo-Class Specification

Keep in mind that :has is not supported in any browsers so the code snippets related to the upcoming pseudo-class won’t work. Relational pseudo-class is defined in selectors level 4 specification which has been updated since its initial release in 2011, so the specification is already well-defined and ready for prototyping and development.

That being said, let’s dive into the :has pseudo-class specification. The idea behind the pseudo-class is to apply styles to a selector if the condition (defined as a regular CSS selector) has been met.

/* Select figure elements that have a figcaption as a child element */ figure:has(figcaption) { /* ... */ }  / Select button elements that have an element with .icon class as a child */ button:has(.icon) { /* ... */ }  / Select article elements that have a h2 element followed by a paragraph element */ article:has(h2 + p) { /* ... */ }

Similar to the other pseudo-classes like :not, relational pseudo selector consists of the following parts.

<target_element>:has(<selector>) { /* ... */ }
  • <target_element>
    Selector for an element that will be targeted if condition passed as an argument to :has pseudo-class has been met. Condition selector is scoped to this element.
  • <selector>
    A condition defined with a CSS selector that needs to be met for styles to be applied to the selector.

Like with most pseudo-classes, selectors can be chained to target child elements of a target element or adjacent element.

/* Select image element that is a child of a figure element if figure element has a figcaption as a child */ figure:has(figcaption) img { /* ... */ }  /* Select a button element that is a child of a form element if a child checkbox input element is checked */ form:has(input[type="checkbox"]:checked) button { /* ... */ }

From these few examples, it is obvious how versatile, powerful and useful the :has pseudo-class is. It can even be combined with other pseudo-classes like :not to create complex relational selectors.

/* Select card elements that do not have empty elements */ .card:not(:has(*:empty)) { /* ... */ }  /* Select form element that where at least one checkbox input is not checked */ form:has(input[type="checkbox"]:not(:checked)) { /* ... */ }

The relational selector is not limited to the target element’s children content and state, but can also target adjacent elements in the DOM tree, effectively making it a “previous sibling selector”.

/* Select paragraph elements which is followed by an image element */ p:has(+img) { /* ... */ }  /* Select image elements which is followed by figcaption element that doesn't have a "hidden" class applied */ img:has(~figcaption:not(.hidden)) { /* ... */ }  /* Select label elements which are followed by an input element that is not in focus */ label:has(~input:not(:focus)) { /* ... */ }

In a nutshell, relational selector anchors the CSS selection to an element with :has pseudo-class and prevents selection to move to the elements that are passed as an argument to the pseudo-class.

.card .title .icon -> .icon element is selected .card:has(.title .icon) -> .card element is selected  .image + .caption -> .caption element is selected .image:has(+.caption) -> .image element is selected

Current Approach And Workarounds

Developers currently have to use various workarounds to compensate for the missing relational selector. Regardless of the workarounds and as discussed in this article, it’s evident how impactful and game-changing the relational selector would be once released.

In this article, we’ll cover two most-used approaches when dealing with the use-cases where relational selector would be ideal:

  • CSS variation classes.
  • JavaScript solution and jQuery implementation of :has pseudo-class.

CSS Variation Classes For Static Elements

With CSS variation classes (modifier classes in BEM), developers can manually assign an appropriate CSS class to elements based on the element’s content. This approach works for static elements whose contents or state won’t change after the initial render.

Let’s take a look at the following card component example which has several variations depending on the content. Some cards don’t have an image, others don’t have a description and one card has a caption on the image.

See the Pen Card variations by Adrian Bece.

For these cards to have the correct layout, developers need to apply the correct modifier CSS classes manually. Based on the design, elements can have multiple variations resulting in a large number of modifier classes which sometimes leads to creative HTML workarounds to group all those classes in the markup. Developers need to keep track of the CSS classes, maintain documentation and make sure to apply appropriate classes.

.card { /* ... */} .card--news { /* ... */ } .card--text { /* ... */ } .card--featured { /* ... */ }  .card__title { /* ... */ } .card__title--news { /* ... */ } .card__title--text { /* ... */ }  /* ... */

JavaScript Workaround

For more complex cases, when the applied parent element style depends on child state or element content that changes dynamically, developers use JavaScript to apply necessary styles to the parent element depending on the changes in the content or state. This is usually handled by writing a custom solution on a case-by-case basis.

See the Pen Filter button state by Adrian Bece.

Relational Selector In jQuery

Implementation of relational :has selector has existed in popular JavaScript library jQuery since 2007 and it follows the CSS specification. Of course, the main limitation of this implementation is that the jQuery line needs to be manually attached invoked inside an event listener, whereas native CSS implementation would be a part of the browser render process and automatically respond to the page state and content changes.

The downside of the JavaScript and jQuery approach is, of course, reliance on JavaScript and jQuery library dependency which can increase the overall page size and JavaScript parsing time. Also, users that are browsing the Web with JavaScript turned off will experience visual bugs if fallback is not implemented.

// This runs only on initial render $  ("button:has(+.filters input:checked)").addClass("button--active");  // This runs each time input is clicked $  ("input").click(function() {   $  ("button").removeClass("highlight");   $  ("button:has(+.filters input:checked)").addClass("highlight"); })

See the Pen Email inputs — valid / invalid by Adrian Bece.

Conclusion

Similar to the container queries, :has pseudo-class will be a major game-changer when implemented in browsers. The relational selector will allow developers to write powerful and versatile selectors that are not currently possible with CSS.

Today, developers are dealing with the missing parent selector functionality by writing multiple modifier CSS classes that needed to be applied manually or with JavaScript, if the selector depends on a child element state. The relational selector should reduce the amount of modifier CSS classes by allowing developers to write self-documented robust selectors, and should reduce the need for JavaScript to apply dynamic styles.

Can you think of more examples where parent selector or previous sibling selector would be useful? Are you using a different workaround to deal with the missing relational selector? Share your thoughts with us in the comments.

References

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
18 Dec

Native CSS Masonry Layout In CSS Grid

by TBSCategories: News

A Level 3 of the CSS Grid specification has been published as an Editor’s Draft, this level describes a way to do Masonry layout in CSS. In this article, I’ll explain the draft spec, with examples that you can try out in Firefox Nightly. While this is a feature you won’t be able to use in production right now, your feedback would be valuable to help make sure it serves the requirements that you have for this kind of layout. So let’s take a look.

What Is A Masonry Layout?

A masonry layout is one where items are laid out one after the other in the inline direction. When they move onto the next line, items will move up into any gaps left by shorter items in the first line. It’s similar to a grid layout with auto-placement, but without sticking to a strict grid for the rows.

The most well-known example of masonry is on Pinterest, and you will sometimes hear people refer to the layout as a “Pinterest layout”.

There are a number of JavaScript tools to help you create this kind of layout, such as David DeSandro’s Masonry plugin.

Can’t We Already Do This In CSS?

We can come close to a masonry layout in a couple of ways. The closest way to achieve the look of this type of layout is to use Multi-column Layout. In the example below, you see something which looks visually like a masonry layout. However, the order of the boxes runs down the columns. Therefore, if the first items have the highest priority (e.g. if this were search results), then the apparent first items in the top row aren’t actually the ones that came back first.

That’s all you need to do to get a simple masonry layout. Using Firefox, you can see that in the CodePen example below.

Note: You can use any of the values used for align-content for align-tracks and justify-tracks. There are some nice examples in the spec of different combinations.

If you set align-tracks: stretch, then any auto-sized items in the layout will stretch. The masonry effect is retained, but anything with a definite size on that axis will not be stretched out of shape.

See the Pen Masonry align-tracks: stretch by Rachel Andrew (@rachelandrew) on CodePen.

The align-tracks and justify-tracks properties can take multiple values. One for each track in the grid axis. This means that in our four-track grid we could have the first track stretching, the second aligned to start, the third aligned to end, and the fourth aligned to center.

This did not seem to work at the time of writing in Firefox.

The spec details that if there are fewer values than tracks, the remaining tracks will use the final specified value. If there are more values than tracks, additional ones will be ignored.

Fallback Behavior

The inclusion of this feature into the grid specification has a definite benefit where creating a fallback layout is concerned. As masonry behaves in a similar way to auto-placement, if a browser doesn’t support masonry then regular auto-placement can be used instead. This is likely to create the gaps in the layout as seen in the earlier example, but is certainly not terrible.

You can see this in action by looking at any of the demos so far using a browser with no support for masonry. You still get a layout. If you wanted to do something entirely different then you could check for support for masonry with feature queries. You could perhaps do the layout with multicol for non-supporting browsers.

@supports (grid-template-rows: masonry) {   /* masonry code here */ }

If the masonry layout is vital then you could check for masonry support using CSS.supports and only use the JavaScript masonry script if there is no support. This would mean that as browsers implement native masonry they would lose the overhead of the scripted version, but it would be there as a polyfill.

Potential Accessibility Concerns

While masonry in CSS is exciting, it is yet another place where content reordering and a disconnection of the document order from the visual order may happen. As I noted on a recent issue that was raised, I feel that we are creating exciting layout possibilities and then needing to tell people to be very careful how they use them.

I’ve written about this problem in Grid, content reordering, and accessibility. I hope that as we move forward with this specification, there are also renewed efforts to find a good way forward with regard to content vs. display order.

Your Feedback Is Needed

We are really lucky to not only have this new spec, but to have a browser implementation to test it in. If you have examples where you have used masonry, why not try replacing your JavaScript with the grid version and see if it works for you? If you run into problems or can’t do something you were able to do in your previous implementation, please let the CSSWG know by raising an issue.

While things are in an experimental state, this is your chance to help influence any changes and point out any problems. So please do, and help make this really great feature even better!

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
12 Nov

Unit Testing In React Native Applications

by TBSCategories: News

React Native is one of the most widely used frameworks for building mobile applications. This tutorial is targeted at developers who want to get started testing React Native applications that they build. We’ll make use of the Jest testing framework and Enzyme.

In this article, we’ll learn the core principles of testing, explore various libraries for testing an application, and see how to test units (or components) of a React Native application. By working with a React Native application, we’ll solidify our knowledge of testing.

Note: Basic knowledge of JavaScript and React Native would be of great benefit as you work through this tutorial.

What Is Unit Testing?

Unit testing is the level of testing at which individual components of the software are tested. We do it to ensure that each component works as expected. A component is the smallest testable part of the software.

To illustrate, let’s create a Button component and simulate a unit test:

import React from 'react'; import { StyleSheet, Text, TouchableOpacity } from 'react-native'; function AppButton({ onPress }) {     return (       <TouchableOpacity           style={[styles.button,               { backgroundColor: colors[color] }]}                  onPress={onPress} >           <Text style={styles.text}>Register</Text>       </TouchableOpacity>     ); } const styles = StyleSheet.create({     button: {         backgroundColor: red;         borderRadius: 25,         justifyContent: 'center',         alignItems: 'center',     },     text: {         color: #fff     } }) export default AppButton;

This Button component has text and an onPress function. Let’s test this component to see what unit testing is about.

First, let’s create a test file, named Button.test.js:

it('renders correctly across screens', () => {   const tree = renderer.create(<Button />).toJSON();   expect(tree).toMatchSnapshot(); });

Here, we are testing to see whether our Button component renders as it should on all screens of the application. This is what unit testing is all about: testing components of an application to make sure they work as they should.

Unit Testing In React Native Applications

A React Native application can be tested with a variety of tools, some of which are the following:

  • WebDriver
    This open-source testing tool for Node.js apps is also used to test React Native applications.
  • Nightmare
    This automates test operations in the browser. According to the documentation, “the goal is to expose a few simple methods that mimic user actions (like goto, type and click), with an API that feels synchronous for each block of scripting, rather than deeply nested callbacks.”
  • Jest
    This is one of the most popular testing libraries out there and the one we’ll be focusing on today. Like React, it is maintained by Facebook and was made to provide a “zero config” setup for maximum performance.
  • Mocha
    Mocha is a popular library for testing React and React Native applications. It has become a testing tool of choice for developers because of how easy it is to set up and use and how fast it is.
  • Jasmine
    According to its documentation, Jasmine is a behavior-driven development framework for testing JavaScript code.

Introduction To Jest And Enzyme

According to its documentation, “Jest is a delightful JavaScript testing framework with a focus on simplicity”. It works with zero configuration. Upon installation (using a package manager such as npm or Yarn), Jest is ready to use, with no other installations needed.

Enzyme is a JavaScript testing framework for React Native applications. (If you’re working with React rather than React Native, a guide is available.) We’ll use Enzyme to test units of our application’s output. With it, we can simulate the application’s runtime.

Let’s get started by setting up our project. We’ll be using the Done With It app on GitHub. It’s a React Native application marketplace. Start by cloning it, navigate into the folder, and install the packages by running the following for npm…

npm install

… or this for Yarn:

yarn install

This command will install all of the packages in our application. Once that’s done, we’ll test our application’s UI consistency using snapshots, covered below.

Snapshots And Jest Configuration

In this section, we’ll test for user touches and the UI of the app’s components by testing snapshots using Jest.

Before doing that, we need to install Jest and its dependencies. To install Jest for Expo React Native, run the following command:

yarn add jest-expo --dev

This installs jest-expo in our application’s directory. Next, we need to update our package.json file to have a test script:

"scripts": {     "test" "jest" }, "jest": {     "preset": "jest-expo" }

By adding this command, we are telling Jest which package to register in our application and where.

Next is adding other packages to our application that will aid Jest to do a comprehensive test. For npm, run this…

npm i react-test-renderer --save-dev

… and for Yarn, this:

yarn add react-test-renderer --dev

We still have a little configuration to do in our package.json file. According to Expo React Native’s documentation, we need to add a transformIgnorePattern configuration that prevents tests from running in Jest whenever a source file matches a test (i.e. if a test is made and a similar file is found in the node modules of the project).

"jest": {   "preset": "jest-expo",   "transformIgnorePatterns": [     "node_modules/(?!(jest-)?react-native|react-clone-referenced-element|@react-native-community|expo(nent)?|@expo(nent)?/.|react-navigation|@react-navigation/.|@unimodules/.|unimodules|sentry-expo|native-base|@sentry/.)"   ] }

Now, let’s create a new file, named App.test.js, to write our first test. We will test whether our App has one child element in its tree:

import React from "react"; import renderer from "react-test-renderer"; import App from "./App.js" describe("<App />", () => {     it('has 1 child', () => {         const tree = renderer.create(<App />).toJSON();         expect(tree.children.length).toBe(1);     }); });

Now, run yarn test or its npm equivalent. If App.js has a single child element, our test should pass, which will be confirmed in the command-line interface.

In the code above, we’ve imported React and react-test-renderer, which renders our tests for Expo. We’ve converted the <App /> component tree to JSON, and then asked Jest to see whether the returned number of child components in JSON equals what we expect.

More Snapshot Tests

As David Adeneye states:

“A snapshot test makes sure that the user interface (UI) of a web application does not change unexpectedly. It captures the code of a component at a moment in time, so that we can compare the component in one state with any other possible state it might take.”

This is done especially when a project involves global styles that are used across a lot of components. Let’s write a snapshot test for App.js to test its UI consistency:

it('renders correctly across screens', () => {   const tree = renderer.create().toJSON();   expect(tree).toMatchSnapshot(); });

Add this to the tests we’ve already written, and then run yarn test (or its npm equivalent). If our test passes, we should see this:

  PASS  src/App.test.js   √ has 1 child (16ms)   √ renders correctly (16ms)  Test Suites: 1 passed, 1 total Tests:       2 passed, 2 total Snapshots:   1 total Time:        24s

This tells us that our tests passed and the time they took. Your result will look similar if the tests passed.

Let’s move on to mocking some functions in Jest.

Mocking API Calls

According to Jest’s documentation:

Mock functions allow you to test the links between code by erasing the actual implementation of a function, capturing calls to the function (and the parameters passed in those calls), capturing instances of constructor functions when instantiated with new, and allowing test-time configuration of return values.

Simply put, a mock is a copy of an object or function without the real workings of that function. It imitates that function.

Mocks help us test apps in so many ways, but the main benefit is that they reduce our need for dependencies.

Mocks can usually be performed in one of two ways. One is to create a mock function that is injected into the code to be tested. The other is to write a mock function that overrides the package or dependency that is attached to the component.

Most organizations and developers prefer to write manual mocks that imitate functionality and use fake data to test some components.

React Native includes fetch in the global object. To avoid making real API calls in our unit test, we mock them. Below is a way to mock all, if not most, of our API calls in React Native, and without the need for dependencies:

global.fetch = jest.fn();  // mocking an API success response once fetch.mockResponseIsSuccess = (body) => {   fetch.mockImplementationForOnce (     () => Promise.resolve({json: () => Promise.resolve(JSON.parse(body))})   ); };  // mocking an API failure response for once fetch.mockResponseIsFailure = (error) => {   fetch.mockImplementationForOnce(     () => Promise.reject(error)   ); };

Here, we’ve written a function that tries to fetch an API once. Having done this, it returns a promise, and when it is resolved, it returns the body in JSON. It’s similar to the mock response for a failed fetch transaction — it returns an error.

Below is the product component of our application, containing a product object and returning the information as props.

import React from 'react'; const Product = () => {     const product = {         name: 'Pizza',         quantity: 5,         price: '$  50'     }     return (         <>             <h1>Name: {product.name}</h1>                <h1>Quantity: {product.quantity}</h1>                <h1>Price: {product.price}</h1>            </>     ); } export default Product;

Let’s imagine we are trying to test all of our product’s components. Directly accessing our database is not a feasible solution. This is where mocks come into play. In the code below, we are trying to mock a component of the product by using Jest to describe the objects in the component.

describe("", () => {   it("accepts products props", () => {     const wrapper = mount(<Customer product={product} />);     expect(wrapper.props().product).toEqual(product);   });   it("contains products quantity", () => {     expect(value).toBe(3);   }); });

We are using describe from Jest to dictate the tests we want to be done. In the first test, we are checking to see whether the object we are passing is equal to the props we’ve mocked.

In the second test, we are passing the customer props to make sure it is a product and that it matches our mocks. In doing so, we don’t have to test all of our product’s components, and we also get to prevent bugs in our code.

Mocking External API Requests

Until now, we’ve been running tests for API calls with other elements in our application. Now let’s mock an external API call. We are going to be using Axios. To test an external call to an API, we have to mock our requests and also manage the responses we get. We are going to use axios-mock-adapter to mock Axios. First, we need to install axios-mock-adapter by running the command below:

yarn add axios-mock-adapter

The next thing to do is create our mocks:

import MockAdapter from 'axios-mock-adapter'; import Faker from 'faker' import ApiClient from '../constants/api-client'; import userDetails from 'jest/mockResponseObjects/user-objects';  let mockApi = new MockAdapter(ApiClient.getAxiosInstance()); let validAuthentication = {     name: Faker.internet.email(),     password: Faker.internet.password()  mockApi.onPost('requests').reply(config) => {   if (config.data ===  validAuthentication) {       return [200, userDetails];     }   return [400, 'Incorrect username and password'];  });

Here, we are calling the ApiClient and passing an Axios instance to it to mock the user’s credentials. We are using a package named faker.js to generate fake user data, such as an email address and password.

The mock behaves as we expect the API to. If the request is successful, we’ll get a response with a status code of 200 for OK. And we’ll get a status code of 400 for a bad request to the server, which would be sent with JSON with the message “Incorrect username and password”.

Now that our mock is ready, let’s write a test for an external API request. As before, we’ll be using snapshots.

it('successful sign in with correct credentials', async () => {   await store.dispatch(authenticateUser('ikechifortune@gmail.com', 'password'));   expect(getActions()).toMatchSnapshot(); });  it('unsuccessful sign in with wrong credentials', async () => {   await store.dispatch(authenticateUser('ikechifortune@gmail.com', 'wrong credential'))   .catch((error) => {     expect(errorObject).toMatchSnapshot();   });

Here, we’re testing for a successful sign-in with the correct credentials, using the native JavaScript async await to hold our inputs. Meanwhile, the authenticateUser function from Jest authenticates the request and makes sure it matches our earlier snapshots. Next, we test for an unsuccessful sign-in in case of wrong credentials, such as email address or password, and we send an error as a response.

Now, run yarn test or npm test. I’m sure all of your tests will pass.

Let’s see how to test components in a state-management library, Redux.

Testing Redux Actions And Reducers Using Snapshots

There’s no denying that Redux is one of the most widely used state managers for React applications. Most of the functionality in Redux involves a dispatch, which is a function of the Redux store that is used to trigger a change in the state of an application. Testing Redux can be tricky because Redux’s actions grow quickly in size and complexity. With Jest snapshots, this becomes easier. Most testing with Redux comes down to two things:

  • To test actions, we create redux-mock-store and dispatch the actions.
  • To test reducers, we import the reducer and pass a state and action object to it.

Below is a Redux test with snapshots. We will be testing the actions dispatched by authenticating the user at SIGN-IN and seeing how the LOGOUT action is handled by the user reducer.

import mockStore from 'redux-mock-store'; import { LOGOUT } from '../actions/logout'; import User from '../reducers/user'; import { testUser } from 'jest/mock-objects';    describe('Testing the sign in authentication', () => {     const store = mockStore();    it('user attempts with correct password and succeeds', async () => {   await store.dispatch(authenticateUser('example@gmail.com', 'password'));   expect(store.getActions()).toMatchSnapshot();   }); });   describe('Testing reducers after user LOGS OUT', () => {     it('user is returned back to initial app state', () => {       expect(user(testUser, { type: LOGOUT })).toMatchSnapshot();     });   });

In the first test, we are describing the sign-in authentication and creating a mock store. We do this by first importing a mockStore from Redux, and then importing a method named testUser from Jest to help us mock a user. Next, we test for when the user successfully signs into the application using an email address and password that matches the ones in our snapshot store. So, the snapshot ensures that the objects that the user is inputting match every time a test is run.

In the second test, we are testing for when the user logs out. Once our reducer snapshot confirms that a user has logged out, it returns to the initial state of the application.

Next, we test by running yarn test. If the tests have passed, we should see the following result:

  PASS  src/redux/actions.test.js   √ user attempts with correct password and succeeds (23ms)   √ user is returned back to initial app state (19ms)  Test Suites: 1 passed, 1 total Tests:       2 passed, 2 total Snapshots:   2 total Time:        31s

Conclusion

With Jest, testing React Native applications has never been easier, especially with snapshots, which ensure that the UI remains consistent regardless of the global styles. Also, Jest allows us to mock certain API calls and modules in our application. We can take this further by testing components of a React Native application.

Further Resources

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
5-using-mobx-state-manager-react-native-applications
07 Oct

Using Mobx As A State Manager In React Native Applications

by TBSCategories: News

State management is an integral part of developing JavaScript applications especially React and React Native applications. In this tutorial, we are going to learn how to use the MobX library for state management; understand the core concepts, some use cases and build a simple example.

Note: Basic knowledge of Javascript and React Native will be of great benefit as you work through this tutorial.

Using MobX In React Applications

State is the data that your component(s) is working with — it holds the data that a component requires and it dictates what a component renders. State management is the process of managing how the state gets updated and passed from one component to another. Monitoring and working with data in an application can be difficult and that’s the need for state management libraries. Handling all the data for your application can be a little daunting especially when your application grows in size and complexity, building your own state management tool is not just time-consuming but difficult, This is why you might want to use a state management library.

However, it is important to know that state isn’t the only data that a component renders, components can also render props passed down to it.

Options For State Management

State management libraries for React Native applications include; React Context API, Redux, MobX and Unstated Next.

Although these state managers each have their advantages and disadvantages, I personally recommend MobX because of its simplicity, minimal boilerplate code — it doesn’t require you change your code, this is because in its core, MobX is and looks like JavaScript; you don’t need a change of architecture to support it (unlike Redux and to a lesser extent Context).

In fact it’s such an invisible abstraction that in many cases if you take out all of the MobX code — the @observable, @computed, @action and observer decorators, your code will work exactly the same (though it’ll have some performance issues) and it’s not limited to a global state. These are some reasons to go forward with MobX as a state manager of choice for your React Native applications.

Although it’s also important to note some issues with using MobX as a state manager, some of which include its avoidance of rules on how to implement it and MobX can be difficult to debug especially when you change state directly in a component without using the @actions parameter.

What Is MobX?

According to the official documentation, MobX is a battle-tested library that makes state management simple and scalable by transparently applying functional reactive programming. MobX treats your application like a spreadsheet. The logic is that Anything that can be derived from the application state, should be done automatically.

Core Principles And Concept Of MobX

MobX differentiates itself from other state managers with the following concepts.

1. State

State is the data your application holds — it’s roughly the entire contents of its memory. This also applies to your components.

2. Derivations

In MobX, anything that can be derived from the state without interactions is a derivation. Examples of derivations include:

  • User interface,
  • Backend add-ons such as changes to a server.

MobX has two mains types of derivations:

  • Computed values
    Computed values are mostly values that can be derived from a current state using pure functions.
  • Reactions
    Reactions in derivations are side effects that happen as a results of changes in your application state. They are similar to a computed value, but instead of producing a new value, a reaction produces a side effect for things like printing to the console, making network requests, incrementally updating the React component tree to patch the DOM, and so on.

A golden rule when using MobX is that when creating a value based on the current state, use a computed value.

3. Actions

Unlike derivations, actions are code that cause changes to an application state — code that changes the state. They are anything that modifies the state. With MobX you can make it explicit in your code, Actions are mostly user events such as inputs, backend data pushes or even scheduled events.

To better understand Actions, let’s look at an example from the MobX documentation.

class Ticker {     @observable tick = 0      @action     increment() {         this.tick++ // 'this' will always be correct     } }  const ticker = new Ticker() setInterval(ticker.increment, 1000)

Here, we set an @observable tick with an initial value of 0. Next, we created a function increment that is also an action that updates the initial value once a tick is made every second.

Observables In MobX

Observables or observable values in MobX are mostly JavaScript primitives, plain objects, classes, arrays and maps. They’re mostly used by first declaring an observable and adding a value to it and then calling it by adding an @observable as shown below:

  observable(value)  @observable classProperty = value

Store Architecture Approach In MobX

MobX principal architecture includes parts and ideas such as services, store, view models and containers — some of which are explained below.

  • Service
    This is usually a function called from a container; they can be used to get data from APIs and be added to the store.
  • Store
    As the name implies, this is the central place of the state used by an application. Usually in MobX, these include the observables, variables, actions and computed properties.
  • Container
    This calls service and puts data from View Model to View Component as React props (should be marked with @observer decorator).

MobX In React And Native Applications

For learning purposes, in this tutorial, we are going to build a simple list app that will allow a user to add, view, and delete list items. We will be using MobX as a state manager in this application to add lists, update and delete them from the app state. However, it’s important to note that you already understand the basic concepts of JavaScript and React.

Without further ado, let’s start!

Setting Up Your Environment

Now that we know how what MobX is and how it works, let me walk you through setting up your project.

First, let’s create a project with the following, write the following code on your terminal to initialise a project:

npx create-react-app listapp

The above code will create a bare React application using the create-react-app package. Move into the project directory:

cd listapp

For this app, we will need three components:

  • TitleInput
    This will contain the title for our project and an input form for adding lists.
  • List
    This will be an input form that would allow a user to add a list. It will have an add button to add our list items.
  • ListsDisplay
    This component will display all of the user list items and also a delete button that’s automatically generated when a user adds a list item.

We will use a Store.js to contain the app state and methods to modify it similar to Redux. Let’s outline what they will be used for.

  • mobx
    This is the state manager we will be using for this project.
  • mobx-react
    This is the official React bindings for MobX.
  • bootstrap
    We will be using bootstrap version 4.5 to style our project.
  • uuid
    This is used to automatically create keys for deleting lists.

Having done that, let’s go ahead and install these packages. I will be installing them with an npm alternative done in yarn:

yarn add mobx mobx-react bootstrap@4.5.0 uuid

Once the packages are installed, we will start our app in development mode by running the code below in our terminal:

yarn start

Setting Up Our App Store

Let’s create a store for our project. First, create a file in the root directory of our project called ListStore, this will be the central location of our app state.

For this app, we will need to create a ListStore in order not to repeat ourselves when we use it in other app components.

/ src/Store.js /  import { observable, action, computed } from "mobx"; import { v4 } from "uuid";  export class List {   @observable value   @observable done    constructor (value) {     this.id = v4()     this.value = value   } }  export class ListStore {   @observable lists = []   @observable filter = ""   @action addList = (value) => {     this.lists.push(new List(value))   }    @action deleteList = (list) => {     this.lists = this.lists.filter(t => t !== list)   }   @computed get filteredLists () {     const matchCase = new RegExp(this.filter, "i")     return this.lists.filter(list=> !this.filter || matchCase.test(list.value))   } }

In the code above, we imported three functions from mobx.

  • observable
    This holds a variable which can be updated in the event of a change in state.
  • action
    Used to modify the application state.
  • computed
    Values that can be derived from the existing state or other computed values, it changes after a state gets modified.

The class List has two object values which are done and value which will hold the initial state of the app and the modification in the case of changes.

We want our new list to automatically create a key so that we can automatically get a delete button once a list is created, Here uuid is used to automatically create keys in our application.

Next, we added an addList function that will add lists when clicked by using the .push() method to push the list in the array we already created in the @observable lists array.

The deleteList function accepts List as a property which is supposed to be the item the user wants to remove. Then we set the value of this.Lists to a new array after we have removed the selected item.

Both addLists and deleteList are actions because they modify the state of our app when changes are made.

Initializing The MobX Store

Next on our list is to import our store in our App.js and use it in our project. 

import React from 'react'; import Navbar from "./components/navbar"; import ListDisplay from "./components/ListDisplay"; import {ListStore} from './ListStore'; function App() {   const store = new ListStore()   return (     <div>       <Navbar store={store}/>       <ListDisplay store={store}/>     </div>   ); } export default App;

Here we imported the TitleInput and ListDisplay components. Then we initialized the store in our App.js in order to be able to pass it as props to the TitleInput and ListDisplay components.

Normally this will throw an error because we’ve not worked on the other components, so let’s do that. Let’s build out the ListDisplay component.

ListDisplay

This component displays all of our added lists and also automatically generates a delete button once a new list is added. 

import React from 'react'  import List from "./List"; import { observer } from 'mobx-react';  function ListDisplay(props) {   const { deleteList, filteredLists } = props.store    return (     <div>         <div className="container">           {filteredLists.map(list => (             <List key={list.id}                list={list}                   deleteList={deleteList}              />           ))}         </div>     </div>   ) } export default observer(ListDisplay)

For this component, we created a function ListDisplay and made it an observer, we also destructure the list and deletelist functions from the store, by doing this, we made it easier to pass then as object props.

Next, we map through filteredLists to return the lists, which we then use in building the individual list by passing the returned item as props to the List component.

Once done, our component should look like this with lists added:

Next is to add a List and TitleInput components.

List Component

Just like our other components, our List component will export the list as an observer in order to help the store watch it for changes. 

import React from 'react' import { observer } from 'mobx-react' function List(props) {   return (     <div className="card">       <div className="card-body">           <div className="d-flex justify-content-between            align-items-center">             <p className={`title $ {props.list.done                ? "text-secondary" : ""}`}>               {props.list.value}               </p>             <div>             <button                onClick={props.deleteList.bind(this, props.list)}                  className="btn btn-danger                    font-weight-bold py-2 px-5 ml-2">                 Delete               </button>             </div>           </div>       </div>     </div>   ) } export default observer(List)

I used the bootstrap to create cards in the first set of divs and also align the delete icon to move towards the right-hand side of the app. First, we created a card component to handle our list and then we created a button tag for the delete button that will accept two objects of this and pass a prop to the list, this will on click, will remove the selected list item from the lists in the page.

Next is to our TitleInput which will contain our input form for adding lists and the title for the project.

TitleInput

Similar to our other projects, we will be adding an @observer function so that the component will be able to accept props from the app Store. 

 import React, { useState } from 'react' import { observer } from 'mobx-react' function Navbar(props) {   const [value, setValue] = useState("")    const {addList} = props.store   const prepareAddList = (e) => {     e.preventDefault()     addList(value)     setValue("")   }   return (     <div className="container mt-3">       <h1 className="title">List App</h1>       <form onSubmit={prepareAddList} className="form-group">           <div className="row ml-lg-2">             <input className="form-control-lg col-12 col-lg-9                col-sm-12 mr-3 border border-secondary"                  value={value} type="text" onChange={(e) =>                    setValue(e.target.value)} placeholder="Enter list"                   />                    <button className="col-lg-2 col-5 col-sm-5 mt-2                    mt-lg-0 mt-sm-2 btn btn-lg btn-success                  font-weight-bold">               Add to List             </button>           </div>       </form>      </div>   ) } export default observer(Navbar)

First, we initialized an initial state. Using React Hooks, we added an initial state called values which we set to an empty string. We use this to hold the value of what is entered in the input field. To know more about React Hooks, you can check out this article by David Abiodun.

Then we called an object for adding lists to the store addList and passed it as props from the app store.

Next we created a function preparedAddList to accept an event object for the input forms, we also added a button for adding the lists manually on click.

Almost done, we need to restart our project server by running:

yarn start

And our TitleInput should look like this:

We are now done with all of our app components, so let’s assemble it in our App.js. To do that, we need to import our components titleInput and ListDisplay. We also need to import our store from the Store component.

In order for MobX to work in our App, we need to pass the MobX store as props in our App and individual components so that they get the properties and functions in the store. 

import React from 'react'; import Navbar from "./components/navbar"; import ListDisplay from "./components/ListDisplay"; import {ListStore} from './ListStore'; function App() {   const store = new ListStore()   return (     <div>       <Navbar store={store}/>       <ListDisplay store={store}/>     </div>   ); } export default App;

Our app should look like this when completed:

Conclusion

MobX is a great state manager especially for React-based applications, building our list app, we’ve learned the basic concepts of MobX, state, derivations, and actions. A working version of this app can be found here:

You can take this further by using MobX in the next application you build that involves the management of state. I’d love to see what new things you come up with. You can read more on MobX and state management applications in the references below.

Resources And References

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
5-using-mobx-state-manager-react-native-applications
28 Aug

Using Mobx As A State Manager In React Native Applications

by TBSCategories: News

Using Mobx As A State Manager In React Native Applications

Using Mobx As A State Manager In React Native Applications

Fortune Ikechi

State management is an integral part of developing JavaScript applications especially React and React Native applications. In this tutorial, we are going to learn how to use the MobX library for state management; understand the core concepts, some use cases and build a simple example.

Note: Basic knowledge of Javascript and React Native will be of great benefit as you work through this tutorial.

Using MobX In React Applications

State is the data that your component(s) is working with — it holds the data that a component requires and it dictates what a component renders. State management is the process of managing how the state gets updated and passed from one component to another. Monitoring and working with data in an application can be difficult and that’s the need for state management libraries. Handling all the data for your application can be a little daunting especially when your application grows in size and complexity, building your own state management tool is not just time-consuming but difficult, This is why you might want to use a state management library.

However, it is important to know that state isn’t the only data that a component renders, components can also render props passed down to it.

Options For State Management

State management libraries for React Native applications include; React Context API, Redux, MobX and Unstated Next.

Although these state managers each have their advantages and disadvantages, I personally recommend MobX because of its simplicity, minimal boilerplate code — it doesn’t require you change your code, this is because in its core, MobX is and looks like JavaScript; you don’t need a change of architecture to support it (unlike Redux and to a lesser extent Context).

In fact it’s such an invisible abstraction that in many cases if you take out all of the MobX code — the @observable, @computed, @action and observer decorators, your code will work exactly the same (though it’ll have some performance issues) and it’s not limited to a global state. These are some reasons to go forward with MobX as a state manager of choice for your React Native applications.

Although it’s also important to note some issues with using MobX as a state manager, some of which include its avoidance of rules on how to implement it and MobX can be difficult to debug especially when you change state directly in a component without using the @actions parameter.

What Is MobX?

According to the official documentation, MobX is a battle-tested library that makes state management simple and scalable by transparently applying functional reactive programming. MobX treats your application like a spreadsheet. The logic is that Anything that can be derived from the application state, should be done automatically.

MobX state architecture
MobX state architecture. (Large preview)

Core Principles And Concept Of MobX

MobX differentiates itself from other state managers with the following concepts.

1. State

State is the data your application holds — it’s roughly the entire contents of its memory. This also applies to your components.

2. Derivations

In MobX, anything that can be derived from the state without interactions is a derivation. Examples of derivations include:

  • User interface,
  • Backend add-ons such as changes to a server.

MobX has two mains types of derivations:

  • Computed values
    Computed values are mostly values that can be derived from a current state using pure functions.
  • Reactions
    Reactions in derivations are side effects that happen as a results of changes in your application state. They are similar to a computed value, but instead of producing a new value, a reaction produces a side effect for things like printing to the console, making network requests, incrementally updating the React component tree to patch the DOM, and so on.

A golden rule when using MobX is that when creating a value based on the current state, use a computed value.

3. Actions

Unlike derivations, actions are code that cause changes to an application state — code that changes the state. They are anything that modifies the state. With MobX you can make it explicit in your code, Actions are mostly user events such as inputs, backend data pushes or even scheduled events.

To better understand Actions, let’s look at an example from the MobX documentation.

class Ticker {     @observable tick = 0      @action     increment() {         this.tick++ // 'this' will always be correct     } }  const ticker = new Ticker() setInterval(ticker.increment, 1000)

Here, we set an @observable tick with an initial value of 0. Next, we created a function increment that is also an action that updates the initial value once a tick is made every second.

Observables In MobX

Observables or observable values in MobX are mostly JavaScript primitives, plain objects, classes, arrays and maps. They’re mostly used by first declaring an observable and adding a value to it and then calling it by adding an @observable as shown below:

  observable(value)  @observable classProperty = value

Store Architecture Approach In MobX

MobX principal architecture includes parts and ideas such as services, store, view models and containers — some of which are explained below.

  • Service
    This is usually a function called from a container; they can be used to get data from APIs and be added to the store.
  • Store
    As the name implies, this is the central place of the state used by an application. Usually in MobX, these include the observables, variables, actions and computed properties.
  • Container
    This calls service and puts data from View Model to View Component as React props (should be marked with @observer decorator).

MobX In React And Native Applications

For learning purposes, in this tutorial, we are going to build a simple list app that will allow a user to add, view, and delete list items. We will be using MobX as a state manager in this application to add lists, update and delete them from the app state. However, it’s important to note that you already understand the basic concepts of JavaScript and React.

Without further ado, let’s start!

Setting Up Your Environment

Now that we know how what MobX is and how it works, let me walk you through setting up your project.

First, let’s create a project with the following, write the following code on your terminal to initialise a project:

npx create-react-app listapp

The above code will create a bare React application using the create-react-app package. Move into the project directory:

cd listapp

For this app, we will need three components:

  • TitleInput
    This will contain the title for our project and an input form for adding lists.
  • List
    This will be an input form that would allow a user to add a list. It will have an add button to add our list items.
  • ListsDisplay
    This component will display all of the user list items and also a delete button that’s automatically generated when a user adds a list item.

We will use a Store.js to contain the app state and methods to modify it similar to Redux. Let’s outline what they will be used for.

  • mobx
    This is the state manager we will be using for this project.
  • mobx-react
    This is the official React bindings for MobX.
  • bootstrap
    We will be using bootstrap version 4.5 to style our project.
  • uuid
    This is used to automatically create keys for deleting lists.

Having done that, let’s go ahead and install these packages. I will be installing them with an npm alternative done in yarn:

yarn add mobx mobx-react bootstrap@4.5.0 uuid

Once the packages are installed, we will start our app in development mode by running the code below in our terminal:

yarn start

Setting Up Our App Store

Let’s create a store for our project. First, create a file in the root directory of our project called ListStore, this will be the central location of our app state.

For this app, we will need to create a ListStore in order not to repeat ourselves when we use it in other app components.

/*** src/Store.js ***/  import { observable, action, computed } from "mobx"; import { v4 } from "uuid";  export class List {   @observable value   @observable done    constructor (value) {     this.id = v4()     this.value = value   } }  export class ListStore {   @observable lists = []   @observable filter = ""   @action addList = (value) => {     this.lists.push(new List(value))   }     @action deleteList = (list) => {     this.lists = this.lists.filter(t => t !== list)   }   @computed get filteredLists () {     const matchCase = new RegExp(this.filter, "i")     return this.lists.filter(list=> !this.filter || matchCase.test(list.value))   } }

In the code above, we imported three functions from mobx.

  • observable
    This holds a variable which can be updated in the event of a change in state.
  • action
    Used to modify the application state.
  • computed
    Values that can be derived from the existing state or other computed values, it changes after a state gets modified.

The class List has two object values which are done and value which will hold the initial state of the app and the modification in the case of changes.

We want our new list to automatically create a key so that we can automatically get a delete button once a list is created, Here uuid is used to automatically create keys in our application.

Next, we added an addList function that will add lists when clicked by using the .push() method to push the list in the array we already created in the @observable lists array.

The deleteList function accepts List as a property which is supposed to be the item the user wants to remove. Then we set the value of this.Lists to a new array after we have removed the selected item.

Both addLists and deleteList are actions because they modify the state of our app when changes are made.

Initializing The MobX Store

Next on our list is to import our store in our App.js and use it in our project.

import React from 'react'; import Navbar from "./components/navbar"; import ListDisplay from "./components/ListDisplay"; import {ListStore} from './ListStore'; function App() {   const store = new ListStore()   return (     <div>       <Navbar store={store}/>       <ListDisplay store={store}/>     </div>   ); } export default App;

Here we imported the TitleInput and ListDisplay components. Then we initialized the store in our App.js in order to be able to pass it as props to the TitleInput and ListDisplay components.

Normally this will throw an error because we’ve not worked on the other components, so let’s do that. Let’s build out the ListDisplay component.

ListDisplay

This component displays all of our added lists and also automatically generates a delete button once a new list is added.

import React from 'react'  import List from "./List"; import { observer } from 'mobx-react';  function ListDisplay(props) {   const { deleteList, filteredLists } = props.store    return (     <div>         <div className="container">           {filteredLists.map(list => (             <List key={list.id}                list={list}                   deleteList={deleteList}              />           ))}         </div>     </div>   ) } export default observer(ListDisplay)

For this component, we created a function ListDisplay and made it an observer, we also destructure the list and deletelist functions from the store, by doing this, we made it easier to pass then as object props.

Next, we map through filteredLists to return the lists, which we then use in building the individual list by passing the returned item as props to the List component.

Once done, our component should look like this with lists added:

The list display component
Lists displayed by `ListDisplay` component. (Large preview)

Next is to add a List and TitleInput components.

List Component

Just like our other components, our List component will export the list as an observer in order to help the store watch it for changes.

import React from 'react' import { observer } from 'mobx-react' function List(props) {   return (     <div className="card">       <div className="card-body">           <div className="d-flex justify-content-between            align-items-center">             <p className={`title $ {props.list.done                ? "text-secondary" : ""}`}>               {props.list.value}               </p>             <div>             <button                onClick={props.deleteList.bind(this, props.list)}                  className="btn btn-danger                    font-weight-bold py-2 px-5 ml-2">                 Delete               </button>             </div>           </div>       </div>     </div>   ) } export default observer(List)

I used the bootstrap to create cards in the first set of divs and also align the delete icon to move towards the right-hand side of the app. First, we created a card component to handle our list and then we created a button tag for the delete button that will accept two objects of this and pass a prop to the list, this will on click, will remove the selected list item from the lists in the page.

The list component
A single list component with the delete button. (Large preview)

Next is to our TitleInput which will contain our input form for adding lists and the title for the project.

TitleInput

Similar to our other projects, we will be adding an @observer function so that the component will be able to accept props from the app Store.

 import React, { useState } from 'react' import { observer } from 'mobx-react' function Navbar(props) {   const [value, setValue] = useState("")      const {addList} = props.store   const prepareAddList = (e) => {     e.preventDefault()     addList(value)     setValue("")   }   return (     <div className="container mt-3">       <h1 className="title">List App</h1>       <form onSubmit={prepareAddList} className="form-group">           <div className="row ml-lg-2">             <input className="form-control-lg col-12 col-lg-9                col-sm-12 mr-3 border border-secondary"                  value={value} type="text" onChange={(e) =>                    setValue(e.target.value)} placeholder="Enter list"                   />                    <button className="col-lg-2 col-5 col-sm-5 mt-2                    mt-lg-0 mt-sm-2 btn btn-lg btn-success                  font-weight-bold">               Add to List             </button>           </div>       </form>      </div>   ) } export default observer(Navbar)

First, we initialized an initial state. Using React Hooks, we added an initial state called values which we set to an empty string. We use this to hold the value of what is entered in the input field. To know more about React Hooks, you can check out this article by David Abiodun.

Then we called an object for adding lists to the store addList and passed it as props from the app store.

Next we created a function preparedAddList to accept an event object for the input forms, we also added a button for adding the lists manually on click.

Almost done, we need to restart our project server by running:

yarn start

And our TitleInput should look like this:

A title input
Title and input component. (Large preview)

We are now done with all of our app components, so let’s assemble it in our App.js. To do that, we need to import our components titleInput and ListDisplay. We also need to import our store from the Store component.

In order for MobX to work in our App, we need to pass the MobX store as props in our App and individual components so that they get the properties and functions in the store.

import React from 'react'; import Navbar from "./components/navbar"; import ListDisplay from "./components/ListDisplay"; import {ListStore} from './ListStore'; function App() {   const store = new ListStore()   return (     <div>       <Navbar store={store}/>       <ListDisplay store={store}/>     </div>   ); } export default App;

Our app should look like this when completed:

Completed list app
(Large preview)

Conclusion

MobX is a great state manager especially for React-based applications, building our list app, we’ve learned the basic concepts of MobX, state, derivations, and actions. A working version of this app can be found here:

You can take this further by using MobX in the next application you build that involves the management of state. I’d love to see what new things you come up with. You can read more on MobX and state management applications in the references below.

Resources And References

Smashing Editorial (ks, ra, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
logo-red-3
06 May

Hybrid Lazy Loading: A Progressive Migration To Native Lazy Loading

by TBSCategories: News

Hybrid Lazy Loading: A Progressive Migration To Native Lazy Loading

Hybrid Lazy Loading: A Progressive Migration To Native Lazy Loading

Andrea Verlicchi

In the past few weeks, you might have heard or read about native lazy loading, which is coming to Chromium 75 in the upcoming months.

“Yeah, great news, but we’ll have to wait until all browsers support it.”

If this was the first thing that crossed your mind, keep reading. I will try and convince you of the opposite.

Let’s start with a comparison between native lazy loading and the good ol’ JavaScript-driven one.

Native Versus JavaScript-Driven Lazy Loading

Lazy loading is a way to improve the performance of a website or web application by maximizing the rendering speed of the above-the-fold images and iframes (and sometimes videos) by deferring the loading of below-the-fold content.

JavaScript-Driven Lazy Loading

In order to lazy load images or iframes, it’s a very common practice to mark them up by replacing the proper src attribute with a similar data attribute, data-src, then to rely on a JavaScript solution to detect when the images/iframes are getting close to the visible portion of the website (typically because the user scrolled down) and to copy the data attributes into the proper ones, then triggering the deferred loading of their content.

<img data-src="turtle.jpg" alt="Lazy turtle" class="lazy">

Native Lazy Loading

According to the native lazy loading specification (still under development), if you want to lazy load images or iframes using the native lazy loading feature, you would just need to add the loading=lazy attribute on the related tag.

<img src="turtle.jpg" alt="Lazy turtle" loading="lazy">

Addy Osmani wrote extensively about this topic in his article “Native Image Lazy-Loading For The Web!” in which he stated that the Google Chrome team are already developing the feature and intend to ship it in Chrome 75.

Other Chromium-based browsers like Opera and Microsoft Edge will also benefit from this development by gaining the same feature in their first update based on Chromium 75.

Get Started With Native Lazy Loading

In case your website’s images are downloaded all at once at page landing without lazy loading, you can enable (where supported) native lazy loading in your website as easily as adding an HTML attribute. The loading attribute tells browsers which images are important to load immediately, and which ones can be downloaded lazily as the users scroll down. The same attribute can be applied to iframes.

In order to tell browsers that a particular image is important so they can load it as soon as possible, you must add the loading="eager" attribute on the img tag. The best practice is to do this for the primary images — typically for the ones that will be displayed above the fold.

<img src="rabbit.jpg" alt="Fast rabbit" loading="eager">

To tell browsers that an image should be downloaded lazily, just add the loading="lazy" attribute. This is a best practice only if you do it only to secondary images — typically for the ones will be displayed below the fold.

<img src="turtle.jpg" alt="Lazy turtle" loading="lazy">

Just by adding the loading attribute to your images and iframes, you will enable your website to use native lazy loading as a progressive enhancement. Your website will gradually benefit from it as support arrives to your users in most modern browsers.

This is the best approach to use if your website is not using any kind of lazy loading today, but if you already implemented a JavaScript-driven lazy loading solution, you might want to keep it while progressively switching to native lazy loading.

The ideal solution would be to start using native lazy loading right away, and use a polyfill to make it work across all browsers. Unfortunately, native lazy loading is not a feature we can polyfill with JavaScript.

No Use For A Polyfill

When a new browser technology is released to a single browser, the open-source community usually releases a JavaScript polyfill to provide the same technology to the rest of the browsers. For example, the IntersectionObserver polyfill uses JavaScript and DOM elements to coordinate Element.getBoundingClientRect() to reproduce the behavior of the native API.

But the case of native lazy loading is different because a JavaScript polyfill for loading="lazy" would have to prevent browsers from loading content as soon as they find a URL in the markup of an image or iframe. JavaScript has no control on this initial stage of page rendering, therefore it is not possible to polyfill native lazy loading.

Hybrid Lazy Loading

If you are not satisfied with having native lazy loading only as a progressive enhancement, or you have already implemented JavaScript-based lazy loading and don’t want to lose this feature in less modern browsers (but still want to enable native lazy loading on browsers that support it), then you need a different solution. Introducing: hybrid lazy loading.

Hybrid lazy loading is a technique to use native lazy loading on browsers that support it, otherwise, rely on JavaScript to handle the lazy loading.

“

In order to do hybrid lazy loading, you need to mark up your lazy content using the data attributes instead of the real ones (such as in JavaScript-driven lazy loading), and to add the loading="lazy" attribute.

<img data-src="turtle.jpg" loading="lazy" alt="Lazy turtle">

Then you require some JavaScript. In the first place, you need to detect whether or not native lazy loading is supported by the browser. Then, do one of the following for every element with the loading="lazy" attribute:

  • If native lazy loading is supported, copy the data-src attribute value to the src attribute;
  • If not supported, initialize a JavaScript lazy loading script or plugin to do that as the elements enter the viewport.

It’s not very hard to write the JavaScript code required to perform these operations on your own. You can detect if native lazy loading is supported with the condition:

if ('loading' in HTMLImageElement.prototype)

If it is, just copy the src attribute value from data-src. If it’s not, initialize some lazy-loading script of your choice.

Here’s a snippet of code that does that.

<!-- In-viewport images should be loaded normally, or eagerly --> <img src="important.jpg" loading="eager" alt="Important image">  <!-- Let’s lazy-load the rest of these images --> <img data-src="lazy1.jpg" loading="lazy" alt="Lazy image 1"> <img data-src="lazy2.jpg" loading="lazy" alt="Lazy image 2"> <img data-src="lazy3.jpg" loading="lazy" alt="Lazy image 3">  <script>   (function() {     if ("loading" in HTMLImageElement.prototype) {       var lazyEls = document.querySelectorAll("[loading=lazy]");       lazyEls.forEach(function(lazyEl) {         lazyEl.setAttribute(           "src",           lazyEl.getAttribute("data-src")         );       });     } else {       // Dynamically include a lazy loading library of your choice       // Here including vanilla-lazyload       var script = document.createElement("script");       script.async = true;       script.src =         "https://cdn.jsdelivr.net/npm/vanilla-lazyload@12.0.0/dist/lazyload.min.js";       window.lazyLoadOptions = {         elements_selector: "[loading=lazy]"         //eventually more options here       };       document.body.appendChild(script);     }   })(); </script>

You can find and test the code above in this live demo.

Still, that is a very basic script, and things can get complicated when you’re using additional attributes or tags to get responsive images (such as the srcset and sizes attributes or even the picture and source tags).

A Little Third-Party Help

For the past four years, I’ve been maintaining an open-source lazy load script named “vanilla-lazyload” and, in a couple of days after Addy Osmani wrote about native lazy loading, the community reacted by asking me if my script could act as a polyfill.

As I explained before, you cannot create a polyfill for the native lazy loading feature, however, I thought of a solution that would make it easier for developers to begin the transition to native lazy loading, without needing to write any of the JavaScript code that I’ve mentioned before.

Starting from version 12 of vanilla-lazyload, you can just set the use_native option to true to enable hybrid lazy loading. The script is only 2.0 kB gzipped and it’s already available on GitHub, npm, and jsDelivr.

Demos

You can start playing around with native lazy loading today by downloading Chrome Canary or Microsoft Edge Insider (dev channel) then enabling the flags “Enable lazy image loading” and “Enable lazy frame loading”. To enable these flags, enter about:flags in your browser’s URL field and search for “lazy” in the search box.

Native Lazy Loading Demo

To analyze how native lazy loading works in the developer tools, you can start playing with the following demo. In this one, not a single line of JavaScript is used. Yes, it’s just full plain native lazy loading.

What to expect: All images are fetched at once, but with different HTTP responses. The ones with the response code 200 are the eagerly loaded images, while the ones with the response code 206 are only partially fetched in order to get the initial information about the images. Those images will then be fetched completely with a 200 response code when you scroll down.

Hybrid Lazy Loading Demo

To analyze how hybrid lazy loading works, you can start playing with the next demo. Here, vanilla-lazyload@12.0.0 is used and the use_native option is set to true:

What to expect: Try the demo on different browsers to see how it behaves. On browsers that support native lazy loading, the behavior would be the same as in the native lazy loading demo. On browsers that do not support native lazy loading, the images will be downloaded as you scroll down.

Please note that vanilla-lazyload uses the IntersectionObserver API under the hood, so you would need to polyfill it on Internet Explorer and less recent versions of Safari. It’s not a big deal if a polyfill is not provided, though, because in that case vanilla-lazyload would just download all the images at once.

Note: Read more in the “To Polyfill Or Not To Polyfill” chapter of vanilla-lazyload’s readme file.

Try Hybrid Lazy Loading In Your Website

Since native lazy loading is coming soon to some browsers, why don’t you give it a chance today using hybrid lazy loading? Here’s what you need to do:

HTML Markup

The simplest image markup is made by two attributes: src and alt.

For the above-the-fold images, you should leave the src attribute and add the loading="eager" attribute.

<img src="important.jpg" loading="eager" alt="Important image">

For below-the-fold images, you should replace the src attribute with the data attribute data-src and add the loading="lazy" attribute.

<img data-src="lazy.jpg" loading="lazy" alt="A lazy image">

If you want to use responsive images, do the same with the srcset and sizes attributes.

<img alt="A lazy image"      loading="lazy"      data-src="lazy.jpg"      data-srcset="lazy_400.jpg 400w, lazy_800.jpg 800w"      data-sizes="100w">

If you prefer to use the picture tag, change the srcset, sizes and src also in the source tags.

<picture>     <source          media="(min-width: 1200px)"          data-srcset="lazy_1200.jpg 1x, lazy_2400.jpg 2x">     <source          media="(min-width: 800px)"          data-srcset="lazy_800.jpg 1x, lazy_1600.jpg 2x">     <img alt="A lazy image"          loading="lazy"          data-src="lazy.jpg"> </picture>

The picture tag can also be used to selectively load the WebP format for your images.

Note: If you want to know more usages of vanilla-lazyload, please read the “Getting Started” HTML section of its readme file.

JavaScript Code

First of all, you need to include vanilla-lazyload on your website.

You can load it from a CDN like jsDelivr:

<script src="https://cdn.jsdelivr.net/npm/vanilla-lazyload@12.0.0/dist/lazyload.min.js"></script>

Or you can install it using npm:

npm install vanilla-lazyload@12

It’s also possible to use an async script with automatic initialization; load it as a ES module using type="module" or load it as AMD using RequireJS. Find more ways to include and use vanilla-lazyload in the “Getting Started” script section of the readme file.

Then, in your website/web application’s JavaScript code, include the following:

var pageLazyLoad = new LazyLoad({     elements_selector: "[loading=lazy]",     use_native: true // ← enables hybrid lazy loading });

Note: The script has plenty of other settings you can use to customize vanilla-lazyload’s behavior, e.g. to increase the distance of the scrolling area from which to start loading the elements or to load elements only if they stayed in the viewport for a given time. Find more settings in the API section of the readme file.

All Together, Using An async Script

To put it all together and use an async script to maximize performance, please refer to the following HTML and JavaScript code:

<!-- In-viewport images should be loaded normally, or eagerly --> <img src="important.jpg" loading="eager" alt="Important image">  <!-- Let’s lazy-load the rest of these images --> <img data-src="lazy1.jpg" loading="lazy" alt="Lazy image 1"> <img data-src="lazy2.jpg" loading="lazy" alt="Lazy image 2"> <img data-src="lazy3.jpg" loading="lazy" alt="Lazy image 3">  <!-- Set the options for the global instance of vanilla-lazyload --> <script>   window.lazyLoadOptions = {     elements_selector: "[loading=lazy]",     use_native: true // ← enables hybrid lazy loading   }; </script>  <!-- Include vanilla lazyload 12 through an async script --> <script async src="https://cdn.jsdelivr.net/npm/vanilla-lazyload@12.0.0/dist/lazyload.min.js"></script>

That’s it! With these very simple and easy steps, you’ll have enabled hybrid lazy loading in your website!

Important Best Practices

  • Apply lazy loading only to the images that you know that will probably be displayed below the fold. Eagerly load the ones above the fold to maximize performance. If you just apply lazy load to all images in your page, you’ll slow down rendering performance.
  • Use CSS to reserve some space for the images before they are loaded. That way, they’ll push the rest of the content below. If you don’t do that, a larger number of images will be placed above the fold before they should, triggering immediate downloads for them. If you need a CSS trick to do that, you can find one in the tips and tricks section of the readme of vanilla-lazyload.

Pros And Cons

NATIVE LAZY LOADING
PROS
  • No JavaScript required;
  • No setup headaches, it just works;
  • No need to reserve space for images using CSS tricks;
CONS
  • It does not work today on all browsers;
  • The initial payload is higher, because of the prefetch of the initial 2 kb for every image.
JAVASCRIPT-DRIVEN LAZY LOADING
PROS
  • It works consistently across all browsers, right now;
  • You can do very highly customized UI tricks, like the blur-in effect or the delayed loading.
CONS
  • It relies on JavaScript to load your content.
HYBRID LAZY LOADING
PROS
  • It gives you the chance to enable and test native lazy loading where supported;
  • It enables lazy loading on all browsers;
  • You can transparently remove the script dependency as soon as native lazy loading support will be widespread.
CONS
  • It still relies on JavaScript to load your content.

Wrapping Up

I’m very excited that native lazy loading is coming to browsers, and I can’t wait for all browser vendors to implement it!

In the meantime, you can either choose to enrich your HTML markup for progressive enhancement and get native lazy loading only where supported, or you can go for hybrid lazy loading and get both native and JavaScript-driven lazy loading until the day native lazy loading will be supported by the vast majority of browsers.

Give it a try! Don’t forget to star/watch vanilla-lazyload on GitHub, and let me know your thoughts in the comments section.

Further Reading on SmashingMag:

Smashing Editorial (dm, il)


Articles on Smashing Magazine — For Web Designers And Developers

9-will-pwas-replace-native-mobile-apps
28 Dec

Will PWAs Replace Native Mobile Apps?

by TBSCategories: News

Will PWAs Replace Native Mobile Apps?

Will PWAs Replace Native Mobile Apps?

Suzanne Scacca

A developer friend of mine has decided to build a progressive web app for his new company. When I asked why he opted for a PWA instead of a native app, he said:

“Because the PWA is the future of the web.”

I thought that was an interesting sentiment. Until he mentioned it, I was of a similar mindset as Aaron Gustafson when he discussed the battle between the native app and PWA. In other words, I thought it really just came down to choice; not whether one was better than the other.

Now that the idea has been planted, though, I can’t help but notice a bunch of people proclaiming their support for the PWA over the native app. Not only that, many of them have gone as far as to say that the PWA will replace the native app entirely.

I’d like to see if that argument holds any water.

An Extensive Guide To PWAs

Progressive Web Applications are more of a methodology that involves a combination of technologies to make powerful web applications. Tell me more about PWAs →

Will PWAs Replace Native Apps?

I’m going to go ahead and answer that question right now:

“Yes, but not for everyone.”

Here’s the way I see it:

The mobile web has definitely improved from where it was just a couple years ago. It’s very rare to run into a website that isn’t 100% responsive in design. That said, I don’t think many mobile websites are 100% mobile-first in design (which I recently hinted at when talking about ditching design elements instead of acquiring more in 2019).

I think for an experience to be truly mobile-first, it would need to be faster and have an app shell. Which is exactly what a PWA offers.

While native apps may provide a superior experience (mostly) to other mobile experiences, I just don’t see a valid reason to spend that amount of money and time to build and manage one… unless your app sits in the top 20 of your category in an app store.

Let me break down the logic I used to come to this decision.

Reason #1: Mobile Web Is Lagging

comScore’s Global Digital Future in Focus report from 2018 makes this point painfully clear:

comScore 2018 mobile web vs. app
comScore 2018 report shows use of mobile web vs. mobile apps (Image source: comScore) (Large preview)

That said, I don’t believe native apps will make mobile websites disappear. I also don’t believe this point counteracts the argument I’m attempting to make today. If this data demonstrates anything, it’s that mobile users strongly prefer the experience of interacting with a digital property through an app interface.

Web developers recognize this preference as well, as this survey from JAXenter demonstrates:

JAXenter PWA survey
JAXenter developer survey about PWAs (Image source: JAXenter) (Large preview)

So, although the mobile web browser has proven to be the less preferred interface through which someone views a website, I don’t think that’ll be the case for much longer as more businesses build PWAs.

The PWA takes all of the things users love about native apps — the app shell, offline access, telephony features, an always-present navigation bar and so on — and gives users a more convenient means for experiencing them.

Look at a brand like Crabtree & Evelyn:

Crabtree & Evelyn PWA
Crabtree & Evelyn PWA example (Image source: Crabtree & Evelyn) (Large preview)

This major retailer has the funds to build a native app counterpart to its website, but it’s chosen not to go that route. Instead, the progressive web app experience gives mobile users the convenience of browsing the online store and making a purchase without having to leave the browser.

Or, if they’re frequent users, they can add this PWA to their home screen and treat it as they would any other app (but more on that later).

Now, let’s look at an example of a PWA that, again, has opted not to go the route of the native app. Instead, Infobae has created a PWA that beats the mobile web experience:

Infobae PWA
Infobae PWA example (Image source: Infobae) (Large preview)

According to Google data, the Infobae PWA has:

  • A 5% bounce rate. The mobile web was 51%.
  • Sessions that are 230% longer than they were on mobile web.
  • Over three times more pages viewed per session than the mobile web.

So, if you’re worried that the PWA won’t cut it as an alternative to the mobile web, you can stop right there. There are clear benefits to building a PWA.

Reason #2: Native App Stores Are Overflowing

Native apps have a lot of competition in the native app stores — many of which are heavy hitters that mobile users are all too familiar with. If your intention is to launch an app in an already congested space, is the app store really the best place for it?

comScore’s report breaks down the top 5 apps based on reach:

comScore top 5 apps
comScore data on the top 5 apps by reach in 2018 (Image source: comScore) (Large preview)

As you can see, the top 5 apps tend to be dominated by the same mobile apps, no matter what part of the world mobile users are located in.

What you might be thinking is, “But what if my app has a unique edge? Isn’t that enough to dominate our niche?”

I could see that, especially if your app is targeted to region-specific mobile users. Then again, you have to consider what sort of app types perform well with mobile app users.

comScore breaks down this point:

comScore total app minute share
comScore data on share of total app minutes (Image source: comScore) (Large preview)

Roughly 70% to 80% of all time spent in mobile apps goes to four categories:

  • Entertainment (like YouTube);
  • Social media (like Facebook);
  • Instant messaging (like Whatsapp);
  • Games (like Fortnite).

If your app concept doesn’t fall into one of those categories, is it worth all that work to place your app in the app store? While I recognize that those aren’t the only kinds of apps that succeed, I just think it would be a risky and expensive gamble to make, especially if your client’s business is brand new. Even then, there are so many cases of well-known entities that have opted not to compete in app stores, despite having a large enough audience or customer base to do so.

West Elm is a great example of a retailer who’s done this:

West Elm PWA
The West Elm PWA (Image source: West Elm) (Large preview)

If you look in the app stores, you’ll find that West Elm has developed two native apps. One is for registries. This makes sense as a mobile app could be conducive to tagging and tracking registry items. It also has one for the West Elm card. If someone is a frequent enough shopper, this type of app might make sense as well.

That said, neither of these native apps is popular with users (at least not in terms of quantity of reviews). So, it was a smart and economical move by West Elm to keep its main shopping interface in the PWA.

Reason #3: PWAs Rank In Search

On a related note, progressive web apps come with the added benefit of ranking in search engines. There are a few reasons why you and your clients should be overjoyed by this:

  1. Your app’s rank in search is contingent upon the SEO work you put into it. If you’re already doing this with your website, this should be easy!
  2. You don’t have to worry about a brand new app getting buried in app store search. Or easily dismissed because of a lack of ratings.
  3. Because a PWA can live in mobile users’ browsers as well as from a button on the home screen, it needs to have a link. And links make for much easier sharing with friends/family/colleagues than telling them the name of an app, hoping they can find it in the store on their own.

Bottom line: if you can give users a tangible link to your app, you can drastically reduce the friction often caused by having one that only exists in the app store.

Plus, I think the searchability aspect is an important one to consider when you think about how people use your app. Take micro-moments, for example.

When a consumer is inspired to:

  • Research something of interest,
  • Go somewhere,
  • Make a purchase,
  • Or do something…

Instead of opening a data-hogging application on their device, they’ll open their search browser and type or speak their query. It’s what we’re all trained to do as consumers. Have a question? Need something? Want help choosing a restaurant? Go to Google.

If your website or app provides an answer to those kinds of questions, you don’t want it hidden away in app stores. You also don’t want to give them a mobile website that offers an option to “Download the App”. You’re only creating extra work for them.

A PWA enables you to place your app directly in search results and to get your users the instant answers they require.

I think this is why e-commerce businesses have especially gravitated towards PWAs, like HobbyCraft.

HobbyCraft PWA
HobbyCraft PWA example (Image source: HobbyCraft) (Large preview)

As you can see here, HobbyCraft is a niche retailer that sells craft supplies out of the UK. It wouldn’t make much sense to put something like this in the app stores — especially when the PWA interface works well enough as it is.

Lancome is another e-tailer that’s made the conscious decision to forego the native app and keep the mobile shopping experience in a PWA format.

Lancome PWA
Lancome e-commerce PWA example (Image source: Lancome) (Large preview)

One important design element I would point you to in both these examples is the Stores icon located in the top navigation bar. For businesses with brick-and-mortar counterparts, there’s no reason to keep your app out of local search in Google.

If you design your PWA correctly, you can make it show up in relevant location-based queries. And if you present an interface that’s reminiscent of a native app — and just as secure as one (since PWAs require HTTPS) — you can compel more mobile users to make a purchase on the spot.

Reason #4: Native Apps Struggle With Retention

For app types that have a hook that compels users to spend time inside a native app and spend money to enjoy the experience further, that’s great. When you find that perfect fit, there’s good money to be made from having a native app. It’s simply a matter of having people willing to commit to the download.

However, as we recently saw, most native apps struggle to retain users.

It doesn’t matter how many initial downloads you get. If mobile users don’t return to the app to engage with your content, purchase subscriptions or upgrades or click on ads, consider it a wasted investment. Unfortunately, that’s the case with a lot of them.

PWAs, on the other hand, don’t require the lofty commitment of having to download an app to one’s device. Heck, users don’t even have to save the PWA to their home screens, if they don’t want to. It’s an overall more convenient experience.

Nevertheless, you may want to urge users to save it for instant access in the future, as The Weather Channel does:

The Weather Channel PWA message
The Weather Channel asks users to save PWA to device. (Image source: The Weather Channel) (Large preview)

Really, what it boils down to is the type of app you’ve built.

The Weather Channel, for instance, provides a service that mobile users will want to use on a daily basis. They could install a native app from the app store with up-to-date weather forecasting, but that app would likely chew through data and battery power a lot more quickly than the browser-based PWA will.

There are other business types that should consider using a PWA for this reason. Think about an online magazine like Forbes.

Forbes PWA add to homescreen
Users can add the Forbes PWA to their home screen just like a native app. (Image source: Forbes) (Large preview)

Highly specialized publications would do really well to develop PWAs for their daily readers.

Again, it provides a much lighter-weight experience for their phones. Plus, PWAs give users offline access, so they can get access to content no matter where they are or how limited their access may be to the Internet. And the home screen presence (if they choose to put the button there), provides a nice little shortcut around the mobile web browser.

Reason #5: PWAs Can Generate More Revenue

With the exception of in-app advertising, Apple and Google take a sizable cut from any sales you make through a native app. This includes paid downloads, in-app purchases or upgrades and subscription fees. At one point, these fees were as high as 30% per sale.

When you’re hoping to spend money on design tweaks, much-needed development updates and promotional advertising, that’s the last thing you want to hear. In other words, a significant portion of the money that starts to trickle in from your native app goes straight into the pockets of app store owners. That doesn’t seem right, especially if you have to pay for app store ads in order to gain visibility within them.

PWAs don’t come with fees to pay-to-play, which means all revenue generated from them go directly to you (or whoever the owner of the business is). This is especially nice if you have an app concept like a local newspaper (such as The Billings Gazette) that probably deals in smaller profit margins to begin with.

Billings Gazette PWA
The Billings Gazette PWA monetization example (Image source: The Billings Gazette) (Large preview)

That’s not the only way you can make more money from PWAs than native apps either.

To start, they’re significantly easier to build than native apps. Plus, managing them after launch requires less of a time commitment and resources from you. Yes, it still needs to be updated and maintained — just like anything else on the web — but you don’t have to deal with the obstacles that come with apps in the app store.

For example, you only have to build one progressive web app. You don’t have to create separate ones to match the guidelines for different mobile devices.

Updates are easier, too, especially if your PWA is based off of a WordPress website. You push an update through the pipeline and it shows up immediately in the live PWA. There’s no need to push updates to the app store admins and wait for their approvals. Everything happens in real time, which means getting new features and money-making initiatives out to the public more quickly.

This is helpful in the case of PWAs like Twitter Lite.

Twitter Lite PWA
The Twitter Lite PWA can stay on the cutting edge in real time (Image source: Twitter) (Large preview)

When going up against a plethora of social media giants that dominate the app stores, having the ability to keep your app updated in real time can serve as a strong competitive edge. This is in addition to all of the other benefits that come from developing your app in a progressive web format.

This is what happened when Twitter put out its PWA.

As this case study from Google shows, Twitter took an incremental approach to optimizing its PWA. As such, they’ve been able to introduce huge improvements to the user experience without much detection from the end user. Their only response to the updates, in fact, has been greater usage of the PWA.

The PWA Is The Future For (Most Of) The Web

Visibility and searchability are known problems with native mobile apps. User retainment is another. And they’re just not sustainable unless you have an idea that’s inherently meant for a native interface that’s sure to bring in money. Mobile games are one example of this. I’d argue that dating apps are another. I used to think social media fell into that category, but Twitter has since proven me wrong.

Based on what I’m seeing online and from what I’ve heard from developer friends and colleagues, I do believe the future is in the PWA.

I think app stores will slowly quiet down as developers realize there are many more benefits to putting a small- to medium-sized company’s app into a progressive web form. The major players will stay put, and companies that have outgrown the bounds of the PWA may eventually move over. But, otherwise, most apps will end up in the progressive web format.

As this trend towards the PWA continues to grow, consumers will become more accustomed to encountering it in search and know that this user-friendly interface is accessible right from their browser. In turn, they’ll only go to the app stores for the kinds of apps that belong there, i.e. messaging, games, entertainment, and some social media. This will create a clearer division between online search and app store search, and further help to improve the overall user experience online.

Smashing Editorial (ra, yk, il)


Articles on Smashing Magazine — For Web Designers And Developers

Newer postsOlder posts
×

Powered by WhatsApp Chat

WhatsApp Chat is free, download and try it now here!

× Chat with Us