UI Code? Application Logic?

JavaScript
1

Can someone explain the following quote from the React course?

You break down your UI into its basic building blocks, and those pieces become the components. This helps to separate the code responsible for the UI from the code responsible for handling your application logic.

I’m not sure what UI code is. I’m assuming that App logic is essentially what decides what will be remembered. Would that make UI code is the actual presentation?

2

UI == user interface, which just means what ever code that makes the elements that the user interacts with

if youve tried to make a site with plain html and had to sift though a bunch of code just to find a particular button or segment of code youd learn how messy things can get

react makes it easier to just separate parts of your html components into super small segments so that you can work with them much easier

3

Good day @PudparK,

I fully get your concern.

Visualize it this way:
A house is an addition of different components which are:

  • The roof
  • The lintel
  • The window
  • The door
  • The cill
  • The wall
  • The floor
    Though they are made of different materials, the components which put together make what we call a house. And those components are fully visible.

When an architect designs a house, he will break it down into basic building blocks and those pieces become the components.

What are the components of a house?

  • The roof, the lintel, the window, the door, the cill, the wall and the floor.

For now, we have a simple house.

How does it apply to UI code?

In our UI(User Interface) code which is nothing else than what the user sees on a page, we have the same structure.

A basic UI page just like a basic house is made of components:

  • A navigation bar
  • A main content area
  • A footer

For now we have a basic UI code which might look like this:

<Navbar/>
<Maincontent/>
<Footer/>

In React, the navigation bar, just as the roof, is a component.
The main content area, just as the wall, is also a component.
The footer, just as the floor, is also a component.

1 Like
4

So for example, I’m building a small application that generates colour schemes, and I’m using React to display everything.

The main part of the application doesn’t have anything to do with React. For example, the key data structure is an object that looks like this:

const exampleColour = {
  id: djti7ff6h0, // pseudo-random ID
  hsl: { h: 270, s: 50, l: 40 },
  rgb: { r: 40, g: 20, b: 60 },
  hex: "#663399",
  css: {
    hsl: "hsl(270, 50%, 40%)",
    hsla: "hsla(270, 50%, 40%, 1)",
    rgb: "rgb(40, 20, 60)",
    rgba: "rgba(40, 20, 60, 1)",
  },
}

I have functions that can build this object from hex, RGB and HSL input. I have functions can modify it and rebuild it with new values, and so on. This is my application logic.

Just to emphasise, this is all just basic JS, neither the object nor any of the functions that create it or operate on it have anything to do with React.

The UI for one colour will look something like this:

import React from "react";

const Swatch = ({colour}) => (
  <svg className=`swatch swatch-${colour.id}` viewBox="0 0 100 100">
    <rect style={ `fill: ${colour.hex}` } width="100" height="100">
  </svg>
);

export Swatch;

And used like

<Swatch colour={ exampleColour } />

The React components just have to be given an object that looks like the example one: they aren’t tied to any of the functionality of the colour generation/modification. And with UI elements that control changes to the colour (buttons, inputs etc), all they do is call the colour generation/modification functions: again, they don’t need to know what those functions do. React components (UI code) call the functions. These change the data (application logic). Then when the data changes, React handles updating the UI and the cycle can begin again.