TIL (Today I learned)
오늘 나는 무엇을 했나요
- React 입문 2주차
- UX집중반
오늘은 어떤 것을 배웠나요
-React 입문 2주차
State
State는 컴포넌트 내부에서 바뀔 수 있는 값으로, UI를 동적으로 업데이트하기 위해 사용이 된다.
State는 useState()라는 리액트 기능을 사용한다.
const [name, setName] = useState("런천미트");
이때 name은 state의 이름이고, setName은 state를 바꾸는 함수, "런천미트" 는 state의 처음값이다.
이때 State를 바꾸기 위해서는 setname의 함수를 변경하면 된다.
setName("스팸"); // 이름을 "스팸"로 변경
다음은 버튼을 누를때 State를 변경하는 방법이다.
function App() {
const [name, setName] = useState("런천미트");
function changeName() {
setName("스팸");
}
return (
<div>
<p>현재 이름: {name}</p>
<button onClick={changeName}>이름 바꾸기</button>
</div>
);
}버튼을 누르게 되면 changename 함수가 실행되고 함수안에는 아까 작성한 State를 변경하기 위한 메인로직으로 인해
이름이 바뀌게 된다!
또 State는 input에서도 쓰인다.
입력값을 State로 관리를 할수가 있는것이다.
function App() {
const [inputValue, setInputValue] = useState("");
function handleChange(event) {
setInputValue(event.target.value);
}
return (
<div>
<input type="text" onChange={handleChange} value={inputValue} />
<p>입력한 값: {inputValue}</p>
</div>
);
}사용자가 입력한 값이 inputvalue라는 state에 저장이 되고 화면에 바로 보이게된다.
즉 React에서 state는 동적인 UI를 만드는 핵심 도구이다!
다음으로는 리액트에서 중요한 불변성이다.
불변성은 메모리에 있는 값을 변경할 수 없는 것을 의미한다.
React에서는 상태(state)의 변화를 감지하기 위해 메모리 주소를 비교합니다. 따라서 상태를 직접 수정하지 않고
새로운 값을 생성해야 한다.
예로
let numbers = [1, 2, 3];
let newNumbers = [...numbers, 4]; // 새로운 배열 생성이렇게 하면 원본 배열은 그대로 유지되고 새로운 배열이 생성된다.
이러한 불변성을 유지하지않을때 문제가 발생한다.
1.예측 불가능한 코드
데이터 구조를 직접 변경하면, 프로그램의 다른 부분에서 해당 데이터 구조를 참조하고 있을 때 그 부분들도 예상치 못한 방식으로 변경될 수 있습니다. 따라서 알 수 없는 버그를 발생시킬 수 있고, 프로그램의 동작을 예측하기 어렵게 만든다.
2. 버그 추적의 어려움
원본 데이터가 여러 곳에서 변경될 수 있다면, 어떤 부분의 코드가 데이터를 변경했는지 추적하기 어려워진다.
이는 특히 큰 코드베이스나 여러 개발자가 협업하는 환경에서 문제가 될 수 있다.
또한 리액트에서는 화면을 리렌더링을 할지 말지를 결정할 때 state의 변화를 확인한다.
하지만 이때 직접 수정을 하여 메모리 주소는 변함이 없고 값만 바뀌는 불변성이 유지않는 현상이 생긴다면
결국은 state가 변했다고 인지하지 못하게 되므로 리렌더링이 일어나지않는다.
- UX집중반 ( UX 프로젝트)
핵심문제정의를 위한 과정 요약
1.가지고있는 데이터중 voc를 어피니티 다이어그램으로 분류를 하고
2.그중에서 쏘카앱 카셰어링의 핵심가치와 그것을 사용하는 소비자의 니즈에 맞는 문제들만 다시 추려서
정리
3.그다음 사용자 여정지도를 그리기전 퍼소나를 작성후 . 퍼소나는 데스크리서치에서 얻은 데이터를 통해
작성을 하였고, 퍼소나를 기준으로 사용자 여정지도를 작성
4.그다음 아이스프레임워크로 문제순위를 정하고 그문제를 5whys로 근본적문제를 찾았는데
이 문제가 정말 핵심문제인지 헷갈리는 상황 발생
그래서 우리는 이게왜 아이스프레임워크에서 1위를 했는지 보다가 ease부분에서 문제가 있다는 팀원들로 인해
아이스프레임워크를 할때 ease가 정말 필요한건지 지웠는데 이것을 지우는게 맞는지에 대해 팀원끼리 갈등이
일어났다.
그후 튜터님의 순회시간에서 관련 피드백을 받게 되었다.
먼저 이 부분에 대한 피드백으로는
아이스 프레임워크는 그중에 하나의 수단일 뿐이고 우리가 팀 내에서 논의를 해봤더니 아이스 프레임워크 1위와는 좀 다른 문제가
1위로 꼽혔다. 근데 이 대화를 할 때 주관적으로 나는 이게 더 중요하다라고 생각해 이렇게 접근하는 것이 아니라 앞에서 발견한
데이터를 기반으로 사용자들이 이러이러한 문제를 겪고 있으니 아이스 프레임워크에서는 순위가 조금 낮았지만 그래도 이 부분을
해결해 준다면 이런 기대 효과가 있을 것 같다. 라는 식으로 토론을 하면서 순위를 정해볼 수는 있으며, 그래서 그 내용을 기반으로
우리는 이 문제를 정의를 하기로 했고 이거를 이렇게 해결하기로 했습니다. 이렇게 접근을 해 주셔도 괜찮다는 피드백을 받았다.
추가로 실무에서는 점수가 높은 문제보다 낮은 문제를 우선 해결할 때도 있다고 하셨다.
즉 아이스 프레임워크로 1위가 선정되더라도 팀에서 근본적인 문제가 아니라고 판단하면 재투표를 진행하거나, 다른 순위의 문제를 기준으로 진행해도 괜찮다 ! 결국 팀 내에서 지금까지의 데이터를 기반으로 다른 방향으로 가고자 한다고 합의를 하였다면 그 방향으로 가는것도 좋다!
또 팀원중에 Ease의 기준을 생각하기 애매하다고 한것에 대한 답변또한 들을수 있었다.
이제 이러한 부분에서 개발을 배우는 이유가 아이스프레임워크를 할때 이것이 디자인으로 다 해결을 할 수있는 것인지 아니면 개발이 들어간다 하더라도 간단한 퍼블리싱이라든가 아니면 CSS에서 바로 수정이 되는 정도라면은 Ease에 기준을 올바르게 잡을수가 있을것이다.
.
.
마지막으로 지금 프로젝트의 목적은 문제를 발견하고 정의하는 과정에서 진짜 문제를 발견하는 경험을 하는 것이지
장표를 화려하게 꾸미고 그러한 결과물이 중요한것이 아니라고 해주셨다.
물론 결과물이 중요하지만 그만큼 더 중요한것이 과정을 어떻게 하였는가가 더 중요하다고 하셨다.
.
.
피드백을 바탕으로 우리는 일단 아이스프레임워크에서 나온 문제들중 순위가 높은것들중 정말 핵심가치와 직결되는 문제들을 토론후 다시 선별을 하였다.
그후 다시 선별한 가장 핵심문제를 잡고 그것에 대한 근본적인 문제를 찾기 위해 5Whys를 진행하기전에 시간이 부족하여 여기까지 하고 끝을냈다..
오늘은 어떤 문제를 겪었고, 앞으로는 어떻게 해결할 것인가요
오늘은 아이스프레임워크를 사용하면서 이게 정말 지금 사용해도 되는건지, 이 결과가 우리가 조사한 핵심가치및 사용자니즈와 그렇게 적합하지않는데도 점수가 가장 높다는 이유로 핵심문제로 선정을 해야하는건지, 아이스프레임워크에서 Ease 부분이 지금 상황에서는 지우고 가도 되는건지에 대한 팀원과의 갈등이 일어났다.
갈등이 일어난 이유는 일단 ease에 대한 기준을 우리가 정하지 않은것도 있지만, 아이스프레임워크에서 기준을 빼면 이것이 필요한지의 대한 의문이 드는사람도있고, 아닌사람도 있어서 그런것같다.
튜터님의 피드백으로 방향을 잡았으나, 앞으로도 문제정의를 하거나 솔루션을 도출할때도 이러한 문제가 발생할텐데
일단 그럴때 마다
방법론을 상황에 맞게 기본 원칙을 이해하고 필요에 따라 조정하고. 100% 완벽히 따르기보다는 프로젝트의 목표와
맥락, 상황에 맞게 유연하게 활용해야겠다. ( 이를 위해서는 무조건 데이터를 근거로 해야하며, 팀원간의 합의도 잊으면 안된다.)