Forem: Rohan Salunke

A cleaner way to compose the sx prop (Material UI v5)

Rohan Salunke — Sat, 25 Dec 2021 13:03:13 +0000

Material UI v5 recently released their new design system the Sx prop. The property includes style properties from CSS and @mui/system. Taking the MUI styling system to the next level. Personally I loved the new style engine from Material UI v5, enabling me to build Web Apps totally using the Material UI's ecosystem. Being used to the clean method of composing CSS classes using classnames package, I found composing and conditionally chaing the sx props a bit unclean.

The Feature

If you're totally new to mui v5, Let's first look at what exactly is sx props. sx prop is prop used in MuiV5 design system, that leverages mui shorthands and native css properties to provide a good styling experience. Below is a basic example of its usage.



import { Box } from "@mui/material";

export default function App() {
  return (
    <Box className="App">
      <h1>mui-sx demo</h1>
      <Box
        // Passing Sx Prop Here
        sx={{
          mt: 2,
          width: 500,
          height: 500,
          background: "yellow",
          border: 1
        }}
      />
    </Box>
  );
}

As seen, sx prop is a JS object comprising of sx properties i.e mui short hands and native css props.

The Problem

Being a JS object, using the sx prop across the markdown might look unclean. There might be usecases where you'd want to reuse some styling or apply conditionally styling.
Lets look at another example where in you need to conditionally color an element based on React state, also enforce modular styling pattern to ensure better reusability.



import { Button } from "@mui/material";
import React from "react";
import { Box, Stack } from "@mui/material";

const sxBox = {
  width: "100%",
  height: 500
};
const sxBordered = {
  border: 1
};
const sxNight = {
  backgroundColor: "#000"
};
const sxDay = {
  backgroundColor: "yellow"
};

export default function App() {
  const [isDay, setDay] = React.useState(true);
  return (
    <>
      <Stack className="App" spacing={2}>
        <h1>mui-sx demo</h1>
        <div>Click toggle button below</div>
        <Box
          sx={
            // Follow are applied unconditionally
            {
              ...sxBox,
              ...sxBordered,
              ...(isDay && sxNight),
              ...(!isDay && sxDay)
            }

            // Follow sx applied when isDay === false
          }
        />
        <Button variant="contained" onClick={() => setDay(!isDay)}>
          Toggle
        </Button>
      </Stack>
    </>
  );
}

As seen in the sandbox, one might need lots of spread operators (...) and ternary conditions to implement composition of the sx prop. If you have worked on huge projects with modular css patterns, scaling above might get ugly.

The Solution

This is where mui-sx comes to rescue. Its a tiny JS library based off classnames, that helps elegantly compse the sx prop. Let's look at the above example written using mui-sx.



import sx from "mui-sx";

import { Button } from "@mui/material";
import React from "react";
import { Box, Stack } from "@mui/material";

const sxBox = {
  width: "100%",
  height: 500
};
const sxBordered = {
  border: 1
};
const sxNight = {
  backgroundColor: "#000"
};
const sxDay = {
  backgroundColor: "yellow"
};

export default function App() {
  const [isDay, setDay] = React.useState(true);
  return (
    <>
      <Stack className="App" spacing={2}>
        <h1>mui-sx demo</h1>
        <div>Click to toggle color</div>
        <Box
          sx={sx(
            // Follow are applied unconditionally
            sxBox,
            sxBordered,
            // Follow sx applied when isDay === true
            {
              condition: isDay,
              sx: sxDay
            },
            // Follow sx applied when isDay === false
            {
              condition: !isDay,
              sx: sxNight
            }
          )}
        />
        <Button variant="contained" onClick={() => setDay(!isDay)}>
          Toggle
        </Button>
      </Stack>
    </>
  );
}

Much Cleaner! The syntax is very close to classnames and if you are someone that has been using classnames for a while then you might enjoy using mui-sx.

Link to the NPM Package: mui-sx

Hope that was helpful 😇
If you have any questions/confusions/suggestions/corrections, Please do post down in the comments section below.

Rohan Salunke (https://okrohan.bio.link/)

Rohan SalunkeFollow

Passionate Engineer😎 JS Evangelist❤ Microfrontends Microservices System Design

Javascript: The 'this' keyword [context] cheatsheet

Rohan Salunke — Mon, 25 Jan 2021 05:57:02 +0000

Javascript context i.e the 'this' keyword is quite a confusing topic in itself. Although, being very simple and semantic, it has been easy for me to forget the rules around context. With further ado, Let me introduce the cheatsheet for the infamous 'this' keyword!

Quick side note: This article is intended as a cheatsheet around JS context, It does not serve as a verbose explanation of the concept. If you are beginner and have not explored the 'context' concept yet, I highly recommend you to read this MDN doc first

Cheatsheet:

Use case	this	Example
Normal Functions
Invoked directly	window	fn() // this -> window
Invoked from object [Implicit Binding]	Invoking object	obj.fn() // this -> obj
Explicit Binding (bind, call, apply)	Passed reference	// --- .call .apply --- // obj.fn.call(otherObj) // this -> otherObj // --- .bind --- // const boundFn = obj.fn.bind(otherObj) boundFn() // this -> otherObj
Invoked in strict mode	undefined [[ If this->window ]]	'use strict' fn() // this -> undefined window.globalFn = fn window.globalFn() // this -> undefined obj.fn.call(window) // this -> undefined
Arrow Functions
Instantiation context: The value of 'this'[Context] when an object instance is created using a constructor.
Invoked [directly OR from object]	Instantiation context	// ----- direct invocation ---- // // Instantiation context: window const fn = () => console.log(this) fn() // this -> window // ----- invocation from obj [class instance] ---- // function myClass(){ this.fn = () => console.log(this) } -- OR -- class myClass { constructor(){ this.fn = () => console.log(this) } } // Instantiation context: obj1 const obj1 = new myClass() obj1.fn() // this -> obj1 // ----- invocation from obj ---- // // Instantiation context: window const obj2 = { fn: () => console.log(this) } obj2.fn() // this -> window
Explicit Binding (bind, call, apply)	Instantiation context [No Effect]	obj.fn.call(otherObj) // this -> window instance.fn.call(otherObj) // this -> instance
Invoked in strict mode	undefined [[ if this -> window ]]	'use strict' fn() // this -> undefined

Some simple examples🤥:

 const fn = function(){
  console.log(this)
 }
 
 const obj = { 
  fn1: fn,
  fn2: function() {
   fn()
  },
  fn3: function(){
   this.fn1()
  },
  fn4: fn.bind(obj),
  fn5: function(){
   this.fn1.call(obj)
  }
 }
 
 obj.fn1()
 // log: obj 
 // as 'fn1' was invoked via the obj object

 obj.fn2()
 // log: window
 // as 'fn2' was invoked via the obj, but
 // the inner 'fn' was invoked directly 

 obj.fn3()
 // log: obj
 // fn3 was invoked via the obj, 'this' pointed to the
 // 'obj'. As 'this' -> obj, the inner execution
 // [this.fn()] is as good 
 // as obj.fn1()

 obj.fn4()
 // log: obj
 // Explicit context binding ;)

 obj.fn5()
 // log: obj
 // hope you're getting a hang of it :P

Some more simple examples 🤥🤥🤥:


 function fnConstructor(){
  const fn = () => console.log(this)
  this.fn1 = () => console.log(this),
  this.fn2 = function(){
   console.log(this)
  }
  this.fn3 = fn,
  this.fn4 = function(){
   fn()
  }
  this.innerObj = { fn }
 }

 const obj = new fnConstructor()
 const obj2 = {
  obFn1: obj.fn1,
  obFn2: () => console.log(this)
 }

 obj.fn1()
 // log: obj (Instantiation context!)
 
 obj.fn2()
 // log: obj (Duhh^^)

 obj.fn3()
 // log: window ;)
 
 obj.fn4()
 // log: obj (Instantiation context!) 

 obj.innerObj.fn()
 // log: obj (Instantiation context!!) 

 obj2.obFn1()
 // log: obj (Instantiation context!!!)

 obj2.obFn2()
 // log: window ;)

Hope that was helpful 😇
If you have any questions/confusions/suggestions/corrections, Please do post down in the comments section below.

Rohan Salunke: LinkedIn Twitter

Don't be one of these React Devs🙄

Rohan Salunke — Sun, 10 Nov 2019 17:41:21 +0000

I have been working with React for a couple of years now and I have seen stupid practices that developers do while working on a React App. In this article, I will list some of these stupid stereotypes and try to explain why they are wrong.
Without wasting time lets start judging😋

The one that knows React but not JavaScript:

Sometimes people ignore learning JS and rush into React.
Remember💡, React is a JS library and you have to make sure you are thorough with it. One step at a time does help.
I would recommend learning these JS concepts and some DOM APIs mentioned in this comprehensive list.

The one who Uses JQuery with React:

I have seen a bunch of people using JQuery along with React for DOM manipulations😑.
It's just pointless, React's main goal is to handle all the DOM changes.
All you have to do is update the state, render the VDOM and React will take care of all the DOM changes.
If you used JQuery and React together, then you should expect some bugs that are hard to debug🙈 as both libraries might update DOM elements at the same time.
Still, If you'd like to continue using JQuery here's a guide integrating it the right way.

The one who complains that React Apps lag

React technically is blazing fast, but everything can become slow if implemented the wrong way😏.
Think of it, React takes care of all the DOM manipulations. To achieve it, it needs to compare the whole DOM tree and update it, which is a very tedious task🥴.
The more the number of DOM elements in your App, the slower the APP will be.
Team React has been doing their part of keeping React performant as possible. React Fiber was a major change!.
But as a developer you have to do your part right, here's a guide to optimize application performance. 'Avoiding Reconciliation' is one of my favorites🤩.

Mr. LibOverflow😷

These are the guys that just try to get around writing code
They will use tonnes of component libraries just to get their task done.
Adding too many packages to your app can increase the overall build size.
You should keep track of the build size, or else the initial app loading would be slow🐢.
Webpack bundle analyzer should help you analyze which package you should be ripping off.
Also external packages are like Magic in your code. Nobody reads how they are working.
At times they might blow up and you might not understand what happened, KEEP THE MAGIC TO MINUMUM, KNOW YOUR CODE!🤓

The one that thinks Redux is must

You need to understand that React is a View Library💡.
How you manage your state is none of its concern.
I don't suggest Redux to beginners, as the learning curve gets steep.
There are tonnes of other state management solutions out there, each with their pros and cons.
Or you can just simply use React hooks and context.
If you are using GraphQL, I would suggest Apollo. I liked their caching algorithm.

Thank you for reading, I hope you liked this post😄. I'd love to hear your thoughts on this, so please feel free to comment!