우리가 class로 컴포넌트를 작성할 때 constructor를 작성하면 항상 super(props)를 적어줘야한다.

 

class Checkbox extends React.Component {
constructor(props) {
super(props);
this.state = { isOn: true };
}
// ...
}

 

 

 

물론, constructor를 작성하지 않고 class fields를 작성하면 이러한 과정은 필요없이 간단하게 작성이 가능하다.

class Checkbox extends React.Component {
state = { isOn: true };
// ...
}

이렇게 적으면 리액트가 알아서 내부적으로 super(props)를 알아서 실행해주니 상관없지만

 

 

 

보다 근본적으로 class 컴포넌트를 이해하기 위해서 constructor 안에 super(props)를 써야하는 이유를 적어볼까 한다.

 

 

 

1. super()를 호출하지 않으면 어떻게 될까?

 

 

class Checkbox extends React.Component {
constructor(props) {
// 🔴 Can’t use `this` yet
super(props);
// ✅ Now it’s okay though
this.state = { isOn: true };
}
// ...
}

우선 알아야 할 것이 있다.

 

Checkbox컴포넌트는 React.Component를 확장해서 만든 것이라는 점이다.

 

그런고로 React.Component의 this는 CheckBox의 this로 생각 할 수 있다.

먼저 super는 부모클래스 생성자의 참조이다.

 

즉, super는 React.Component의 constructor를 가리키는 것이다.

 

그리고 자바스크립트는 언어적 제약사항으로서 이런 extends가 사용되었을 때 super를 호출하기 전에는 this를 호출 할 수 없다.

 

 

 

 

어째서 이런 제약사항을 걸은 걸까? 여기에는 합리적인 이유가 있다.

아래의 예시를 보자.

 

class Person {
constructor(name) {
this.name = name;
}
}
class PolitePerson extends Person {
constructor(name) {
this.greetColleagues(); // 🔴 This is disallowed, read below why
super(name);
}
greetColleagues() {
alert('My name is ' + this.name + ', nice to meet you!');
}
}

 

 

super를 호출하기 이전에 this를 사용하는 것이 가능하다고 가정하면 이런 경우 코드를 이해하기 난해해진다.

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

PolitePerson의 constructor에서 this.greetColleagues();를 호출 했다.

 

greetColleagues매서드의 내용은  alert('My name is ' + this.name + ', nice to meet you!');이다. 

 

여기서 문제가 생긴다.

 

this.name은 부모컴퍼넌트인 Person안에 있는 내용이다. 

 

그래서 super(name)을 통해 불러와야 하는데 이 super(name)이 this.greetColleagues 밑에 있다.

 

즉, this.name을 불러오지도 못했는데 greetColleagues는 this.name을 불러오고 있는 것이다.

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

 

이렇게 애매한 경우를 허용하지 않기 위해서 자바스크립트는 언어 차원에서 this 사용 전에 super호출을 강제하는 것이다.

 

 

 

 

2. 왜 super()에다가 props를 인자로 전달해야 할까?

 

 

우선은 간단하게 설명하자면  super()안에 props를 넣는 이유는 React.Compoent도 역시 객체가 생성될 때

 

props 속성을 초기화하기 위해서다.

 

// Inside React
class Component {
constructor(props) {
this.props = props;
// ...
}
}

 

그러나 props 전달 없이 super()를 호출하더라도 render 함수 및 기타 메소드에서 여전히 this.props를 사용할 수 있다.

 

왜냐하면 리액트는 우리가 작성한 컴포넌트의 생성자 호출 이후 해당 객체에 props 속성을 세팅해주기 때문이다.

 

그래서 리액트는 props를 super의 인자로 전달하는 것을 실수로 빠뜨리더라도 정상적으로 동작되는 것을 보장해준다.

 

 

그렇다면 사람들은 그러면 리액트가 세팅해주는데 그냥 super()쓰면 되지 뭐하러 super(props)를 쓰냐고 생각할 수 있다.

하지만 잘 읽어보자 

 

'생성자 호출 이후'

 

 

즉, 그냥 super()라고 하면 생성자 호출 이후 이전인 '생성자 내부'에서는 this.props는 undefined가 될 것이다.

// Inside React
class Component {
constructor(props) {
this.props = props;
// ...
}
}
// Inside your code
class Button extends React.Component {
constructor(props) {
super(); // 😬 We forgot to pass props
console.log(props); // ✅ {} 예제라서 빈배열이라고 나와있지만 실제로 사용할 땐 많은 값이 들어있다.
console.log(this.props); // 😬 undefined
}
// ...
}

 

console.log(this.props) -> undefined가 나온다.

 

이것이 super(props)를 적어야 하는 이유다!

 

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

공부하는데 있어 한가지 헷갈리는 점을 유의하자.

 

// Inside React
class Component {
constructor(props) {
this.props = props;
// ...
}
}
// Inside your code
class Button extends React.Component {
constructor(props) {
super(props);
console.log(props); // ✅ {} 예제라서 빈배열이라고 나와있지만 실제로 사용할 땐 많은 값이 들어있다.
console.log(this.props);
}
// ...
}

1. props는 '키:값'으로 이루어진 객체이다.

 

2. 여기서 constructor(props) , super(props), console.log(props)에 찍힌 props는 같은 props이지만

 

this.props에 있는 props는 다른 props다.

 

즉, 

 

// Inside React
class Component {
constructor(props) {
this.props = tt;
// ...
}
}
// Inside your code
class Button extends React.Component {
constructor(tt) {
super(tt);
console.log(tt); // ✅ {} 예제라서 빈배열이라고 나와있지만 실제로 사용할 땐 많은 값이 들어있다.
console.log(this.props);
}
// ...
}

이렇게 해도 된다는 것이다.

 

tt객체에 들어온 값을 this.props 객체에  tt객체를 집어넣는거다!

 

 

 

 

 

 

 

 

 

 

 

 

11. 컴포넌트 만들기

 

 

 

<App.js>

import React, { Component } from 'react';
import './App.css';
class App extends Component {
render(){
return (
<div className="App">
Hello, React!!
</div>
)
}
}
export default App;

app이라는 클래스를 만들고 리액트의 컴퍼넌트라고하는 리액트가 갖고 있는 클래스를 상속해서

우리가 새로운 클래스를 만드는거다.  그리고 클래스는 render라는 매소드를 가지고 있다. 

 

 

App.js에 새로운 컴포넌트를 만들자.

import React, { Component } from 'react';
import './App.css';
class Subject extends Component {
render() {
return (
<header>
<h1>WEB</h1>
world wide web!
</header>
);
}
}
export default App;

여기에 render라고 적혀 있는데 우리가 알고 있는 함수는

 

function render () {}라고 적혀야 하지만 

 

자바스크립트의 최신 스펙에 들어가 있는 클래스는 안에 소속되는 함수는 function을 생략한다.

 

그리고 거듭 언급하지만 컴퍼넌트를 만들 떄는 그 컴퍼넌트는 반드시 하나의 최상위 태그로 시작해야한다.

(여기서는 header태그가 최상위 태그이다.)

 

새로만든 컴퍼넌트를 App컴퍼넌트에 적용하자.

 

 

import React, { Component } from 'react';
import './App.css';
class App extends Component {
render(){
return (
<div className="App">
<Subject></Subject>
</div>
)
}
}
export default App;

 

 

 

 

개발자도구로 보면 리액트 코드에서는 그냥  <subject>인데 리액트가 코드를 처리한 다음에 최종적으로

 

웹브라우저가 알아 들을 수 있는 헤더(header)라는 이름의 태그와 그 안의 내용으로 바꿔 준 것이다.

 

즉 ,웹브라우저는 이 세상에 리액트라는 기술이 있는지 모른다!

 

 

그리고 우리가 위에서 짠 코드는 자바스크립트가 아니라 유사 자바스크립트다. 

왜냐하면 ruturn안에 있는 부분은 그냥 태그를 써버렸기 때문이다.

 

우리가 작성하고 있는 이 코드는 자바스크립트랑 거의 비슷한데 태그들을 우리가 그대로 사용할 수 있게 해주는 

페이스북에서 만든 컴퓨터 언어가 jsx이다.

 

우리가 jsx로 코드를 작성하면 그것을 CRA가 알아서 자바스크립트 코드로 컨버팅 해주는 것이다.

 

 

 

 

 

 

11.2 컴포넌트 만들기2

 

 

 

 

<App.js>

import React, { Component } from 'react';
import './App.css';
//Subject 컴포넌트 생략함
Class TOC extends Component{
render(){
return (
<nav>
<ul>
<li><a href="1.html">HTML</a></li>
<li><a href="2.html">CSS</a></li>
<li><a href="3.html">JacaScript</a></li>
</ul>
</nav>
)
}
}
Class Content extends Component{
render(){
return (
<article>
<h2>HTML</h2>
HTML is HyperText Markup Language.
</article>
)
}
}
class App extends Component {
render(){
return (
<div className="App">
<Subject></Subject>
<TOC></TOC>
<article></article>
</div>
)
}
}
export default App;

App.js에 새로운 TOC,Content라는 컴포넌트들을 만든 후 추가하였다.

 

이렇게 컴포넌트를 사용하여 정리하니 App컴포넌트의 내용이 매우 심플해졌다.

 

우리가 리액트에서 컴퍼넌트를 바라보는 첫 번쨰 시각은 정리정돈의 도구로 보는 것이다.

 

 

 

 

 

 

 

 

07. JS코딩하는 법

 

 

 

 

 

 

Create react app이 우리에게 제공하는 샘플 어플리케이션을 수정하는걸 출발점으로 해서 개발을 시작하게 될 것이다.

 

어떤 디렉터리 구조를 가지고 있고 어디를 수정하면 우리가 코딩을 할 수 있는지 알아보자.

 

크게 srcpubilc이라는 디렉토리가 있다.

 

그 중 public은 index.html이 있다.

 

 

<index.html>실행결과

 

 

지금 우리가 보고있는 리액트로 만든 어플리케이션이 웹브라우저 상에서는 index.html을 실행한 결과다.

 

 

<index.html>

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<link rel="icon" href="%PUBLIC_URL%/favicon.ico" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<meta name="theme-color" content="#000000" />
<meta
name="description"
content="Web site created using create-react-app"
/>
<link rel="apple-touch-icon" href="%PUBLIC_URL%/logo192.png" />
<link rel="manifest" href="%PUBLIC_URL%/manifest.json" />
<title>React App</title>
</head>
<body>
<noscript>You need to enable JavaScript to run this app.</noscript>
<div id="root"></div> <!--이 부분을 주목하자!-->
</body>
</html>

 

 

우리가 index.html에서 신경 쓸 부분은 <div id=“root”></div>이다.

 

컴퍼넌트들은 저 안에 들어간다.

 

그러면 아이디가 root인 태그 안쪽에 들어가는 컴퍼넌트들은 어떤 파일을  수정해서 만들 수 있을까?

 

바로 src디렉토리안에 있는 파일들이다.

 

그래서 우리가 앞으로 개발 작업을 하게 되면 대부분의 파일은 src라는 디렉토리 안에 넣게 될 것이다.

 

src에서 index.js로 들어가면 

 

 

<index.js>

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import reportWebVitals from './reportWebVitals';
ReactDOM.render(
<React.StrictMode>
<App />
</React.StrictMode>,
document.getElementById('root')
);

 

document.getElementById('root’)가 있는데  이것은 <div id=“root”>를 말하는 것이다.

 

 

그리고 

<App />이  리액트를 통해 만든 사용자 정의태그 즉 컴퍼넌트이다.

 

그리고 저 컴퍼넌트의 실제 구현은  App.js의 App에 있다.(import App from './App’;)

 

 

 

<App.js>

import logo from './logo.svg';
import './App.css';
function App() {
return (
<div className="App">
<header className="App-header">
<img src={logo} className="App-logo" alt="logo" />
<p>
Edit <code>src/App.js</code> and save to reload.
</p>
<a
className="App-link"
href="https://reactjs.org"
target="_blank"
rel="noopener noreferrer"
>
Learn React
</a>
</header>
</div>
);
}
export default App;

App.js로 들어가면 App클래스가 있는걸 볼 수 있다.

 

 

개발자 도구로 확인하면 해당내용이 실제로 <div id=“root”>에 들어가 있다.

 

Class App의 내용을 바꾸면 브라우저에 나오는 내용도 바꿀 수 있다.

 

 

내용을 바꿀 때 주의할 점은 반드시 리액트는 하나의 태그 안쪽에 나머지 태그들이 있어야 한다.

 

가장 바깥쪽에는 태그 하나가 있어야 한다. 없으면 에러가 난다.

 

 

 

 

 

 

08. CSS코딩 하는 법

 

 

 

 

리액트에서의 방법이라기 보다는 create react app의 지배 하에서 css를 어떻게 하면 되는가를 살펴보는 것이다.

 

Index.js에 import './index.css’;라는 것이 있다. Index.css로 들어가자

 

<index.js>

 

<index.css>

 

그 다음 위 사진과 같이 바꿔주면 화면에 css가 적용되어 나타난다.

 

 

이번엔 App.js로 들어가면 import './App.css’;가 있다

 

<App.js>

 

이건 App.js안에 들어있는 리액트의 컴퍼넌트가 로드 됐을 때 app.css도 같이 로드가 될 것이고 그러면 이제 디자인도 같이

할 수 있게 되는 것이다.

 

, App이라고 하는 컴퍼넌트에 디자인을 안에 넣는다.  이렇게 생각하면 된다.

 

 

 

 

 

 

09 배포하는 법

 

 

 

 

이번엔 deploy하는 법을 알아보자 

 

지금까지 우리가 만든 간단한 리액트 앱을 살펴보자

 

 

 

개발자 도구의 network탭을 들어가고 리로드하면 resources의 크기가 1.7mb나 된다.

 

기능이 하나도 없는데 이러는 이유는 리액트가 개발의 편의성을 위해서 여러가지 기능을 지금 추가해 놓은 상태이기 때문이다. 

그래서 create react app의 개발 환경은 상당히 파일의 무게가 무겁다.

 

이걸 개발자 자신만 쓰면 문제가 없는데 다른 사용자들이 1.7mb 짜리를 쓰게 하면 안된다!

 

게다가 이렇게 주면 보안적인 문제도 생길 수 있다.

 

 

 

그래서 프로덕션 모드의 어플리케이션을 만들 때는  빌드를 해야한다.

 

npm run build

 

를 하면 build디렉토리가 생긴다.

 

 

Build 디렉토리에서 index.html로 들어가면 공백이 하나도 없고 읽을 수가 없다. 

왜냐하면 create react app이 실제 프로덕션 환경에서 사용되는 앱을 만들기 위해서

 

우리가 이미 가지고 있는 index.html파일에서 공백과 같이 불필요하게 용량을 차지하는 정보를 모두 살균시킨 것이다.

 

그 결과가 이것인 것이다. 그래서 용량이 훨씬 작다

 

그리고 src에서 작업했던 파일들도 create react app이 용량을 줄인다든지 보안쪽으로든지 심미적으로 좋지 않은 내용들도

없앤다든지 해서 빌드에 있는 index.html이 그것을 로드할 수 있도록 우리 대신에 알아서 처리해주는 것이다.

(여기서 심미적인 것은 디자인을 말하는 것이 아니다.)

 

 

결론적으로 우리가 실제로 서비스할 때는 빌드 안에 있는 파일들을 쓰면 된다라는 것이고

 

웹서버에서 문서를 찾는 최상위 디렉토리에다가(document route) 빌드 디렉토리 안쪽에 있는 파일을 위치시키면 된다.

 

 

그러면 실서버 환경이 완성 된 것이다.

 

npm install -g server 

 

npm을 통해 설치할 수 있는 간단한 웹서버이다.

이렇게 하면 우리는 이 컴퓨터 어디에서나 serve 라는 명령어를 통해서 웹 서버를 설치할 수 있다.

 

 

npx serve

 

npx로 한번만 실행 시킬 웹서버를 다운로드 받아 실행시킬 수 있다.

 

여기에 -s build를 붙이면 serve라는 웹 서버를 다운받아서 실행 시킬 때 빌드(build)라는 디렉토리를 document route로 하겠다

라는 것이 -s이다.

 

 

 

 

Npx serve -s build를 치면 위와같이  Local:  http://localhost:5000 를 알려주는데 들어가면 

똑같이 동작을 한다.

 

 

여기서 다시 개발자 도구를 들어가고 Network에 들어가면 리소스가 147kb로 줄어있다.

동작하는 모습은 똑같지만 엄청나게 리소스가 줄어들었다!

 

 

참고)Public디렉토리는 우리가 create react app에 서 npm run start를 했을 때 파일을 찾는 document route이다.

 

 

 

지금까지 01~09강의를 통해서 설치 - 코딩 - 실행-배포하는 방법을 알아보았다.

 

 

 

 

 

 

 

 

 

 

<div> main은 <body>태그를 부모로 갖는 태그이다.

 

.main {width:100% ; height 100%}로  화면전체를 블록으로 가지고 있다.

(예제에서는 설명을 위해서 처음 보이는 높이를 1000px로 했다.)

 

main은 flex값이 주어졌다.

 

feedmain.right는 main의 자식이다.(flex의 item들이다.)

 

feed의 댓글추가 버튼을 누르면 화면의 밑에 댓글이 추가가 되며 스크롤이 생긴다.

 

 

 

 

 

 

 

 

position: relative의 경우

 

position: sticky의 경우

 

 

 

 

 

스크롤이 생길 때의 경우의 수.

 

 

 

 

 

 

 

top > margin-top일 경우

 

 

 

padding 과 margin-top에 의해 박스의 크기가 900px로 정해진다.

top은 100px이지만 공간이 부족하여 50px까지만 나타나고 있다.

 

댓글추가버튼을 눌러 스크롤을 생성하였다.

빨간색 커다란 네모가 현재 보이는 화면이다.

 

댓글을 추가하여 30px이 늘어났기에 top이 30px만큼 늘어나 80px이 되었다.

그만큼 main right는 밑으로 밀러 내려간다.

 

 

 

댓글을 더 추가하여 스크롤을 길게 만들었다.

 

공간이 여유있어 top:100px을 모두 표현하였고 그만큼 main.right는 50px만큼 밑으로 내려갔다.

 

 

 

스크롤을 내리면 position:sticky가 아닌 feed는 그 처음에 padding값만 적용되고 그 상태로 계속 가만히 있는다.

main-right는 현재 보이는 화면을 기준으로 padding값이 계속 적용되고 top:100px역시 계속 적용된다.

 

 

 

그렇게 계속 내리다보면 main-right박스가 화면보다 50px 먼저 스크롤 끝에 도달한다.

 

 

 

 

스크롤 자체는 완전히 끝난게 아니기 때문에 여기서 더 내리면 top:100px을 유지할 공간이

없어져서 무너지게 된다.

 

 

 

 

스크롤이 끝에 도달하면 top:50px이 된다.

 

 

 

 

 

 

 

top < margin-top일 경우

 

 

 

padding, margin-top에 의해 main-right의 상자 크기가 850px로 지정되었다.

 

top:50px도 적용중이지만 margin-top:100px값에 묻혀서 티나지 않는 상태다.

 

 

 

 

 

 

댓글추가버튼을 눌러 30px만큼 높이를 늘려서 스크롤을 생성하였다.

 

 

 

 

스크롤이 생성된 후 30px만큼 내리니 margin-top 값이 30px만큼 줄어들어 70px이 되었다.

그리고 main-right박스가 30px만큼 위로 올라간다.

 

 

 

댓글을 많이 추가해 스크롤을 길게한 후 스크롤을 내리면 margin-top:100px은 

top:50px까지 내려오고 그 후로는 고정된다.

 

main-right박스도 50px만큼 올라온 후 계속 고정된다.

 

 

 

스크롤이 끝에 도달할 때까지 변하지 않는다.

 

 

 

 

 

 

 

top = margin-top일 경우

 

 

 

 

댓글버튼을 만들어 스크롤 생성.

 

 

 

margin-top과 top의 값이 같기 때문에 main-right의 위치가 변하지 않고 계속 고정된다.

 

 

댓글이 많아져 스크롤이 길어져도

 

 

 

 

스크롤이 끝에 도달해도 고정된건 마찬가지다.

 

 

 

 

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 

main은 flex값을 줬고 feed와 main-right는 그 아이템이다.

 

그래서 기본값으로 부모컨텐츠(main)의 box높이를 따라간다.

 

그러니 댓글추가로 높이를 높여 스크롤이 생겨도 처음화면의 main 박스의 높이를 따라가기 때문에

main-right의 높이가 늘어나거나 하지 않는다.

 

 

------------------------------------------------------------------------------------------------------------

 

솔직히 그냥 main에다가 align-items:flex-start를 주고

 

main-right가 자기 컨텐츠 높이 만큼만 갖게 하는게 맘 편하다.

 

 

align-items:flex의 경우

 

top<margin-top, top=margin-top의 경우 똑같다.

 

top>margin-top (사실 여기선 margin-top은 필요없는 값이다.)

 

 

align-items:flex-start로 하면 main-right는 박스높이가 컨텐츠(내용물)  높이이다.

(margin-top으로 박스높이가 결정되지 않는다.)

 

top:100px을 주는데 공간이 부족하지 않으면 그냥 적용된다.

 

 

컨텐츠의 높이가 430px이라 top:70px까지 밖에 못나왔다.

그러면 상위박스의 높이가 높아지면 top:100까지는 커지다가 그 후로 고정될 것이다.

 

 

 

//////////////////////////////////////////////////////////

 

+추가

 

Positon:sticky는 가장가까운 스크롤 되는 조상!!!!! 바로 위에있는 main에걸리는게 아니었다 ㅠㅠ body가 스크롤 되면 body에 걸리는거다!!

 

 

https://developer.mozilla.org/ko/docs/Web/CSS/position

요소를 일반적인 문서 흐름에 따라 배치하고, 테이블 관련 요소를 포함해 가장 가까운, 스크롤 되는 조상과, 표 관련 요소를 포함한 컨테이닝 블록(가장 가까운 블록 레벨 조상) 을 기준으로 top, right, bottom, left의 값에 따라 오프셋을 적용합니다. 오프셋은 다른 요소에는 영향을 주지 않습니다.

 

그러니 main에 걸린 height:100vh를 지운다. 애초에 스크롤이 생겨야하는건

main이 아니라 body이기 때문이다. 

 

main에 스크롤이 생길려면 메인범위 바로 옆에 스크롤이 생겨야하는 것이다.

 

만약에 main에 height: 100vh를 주면 메인의 높이는 피드가 여러개가되면

분명히 1000px이 넘을텐데 vh때문에 1000px로 고정되는 것이다.

 

나중에 피드가 여러개가된 메인의 높이를 구해야할 때가 있으면 vh때문에 구하지

못하게 되버리는 것이다.

 

그러니 내가 기존에 했던 바디의 overflow를 숨기고 메인을 바디크기로 늘리고

vh를 준건 하면 안되는 짓이다.

 

전체화면의 높이가 1000px이라고 했을 때 

main_right에 100vh를 주면 얘의 높이가 1000px이 된다. 그런데 top:100px을

주면 1000픽셀이 보이는 화면밖으로 100px만큼 삐져나온다. 그래서 

스크롤을 내리다보면 스크롤보다 먼저 삐져나온부분이 바닥에 닿게되는데 

그렇게되면 나머지 스크롤을 더 내리면 삐져나온부분이 다시 스크롤 안으로 들어가면서

Top:100px이 깨지고 top은 결국 0px이 된다.

 

그래서 높이를 100vh를 주지말고 화면의 높이가 1000px이고 top을 100을 줘야

한다면  높이를 900px안쪽으로 만들자 ex) 400px

 

만약에 화면에 넘어갈정도로 main-right가 길게 형성되면 어떻해요? 라고 물어볼 수 있는데

애초에 main_right는 화면에 고정되게 만들려고 한 녀석인데 

ui를 화면이 넘어갈 정도로 구성하는게 말이 안된다. 

그러면 애초에 고정할 생각을 하지 말아야지!

 

 

 

'CSS' 카테고리의 다른 글

TIL#01 생활코딩 -WEB2 상-  (0) 2021.05.05

+ Recent posts