feat: Add edit[id] page

[lsc2159]

• Add edit page [id:1,2,3]
• Basic screen configuration for simple code operation understanding
• Implementing dashboard, configuring components for expansion (Refer to the photo)
• When I connect to the API, Create a services/featureFlags.ts file to change it to handle actual API requests

[HakSooDev]

고생 많으셨습니다.

[HakSooDev]

@lsc2159
반복되는 타입들, Variation, FeatureFlag 는 src/types 에 넣으면 매번 선언 하지않아도 될것 같습니다.

[HakSooDev]

개인적으로는 targetFeatureFlag 가 조금 더 가독성이 좋지않을까 싶습니다

[HakSooDev]

여기서 살짝 null 이랑 undefined 에 차이가 있는데 보통 state 들은 undefined 보다는 null 로 표기를 해서 임의적으로 placeholder 을 놔두는게 나중에 조금 더 디버깅이나 타입 관리하기 쉬운편인것 같습니다.

  const targetFeatureFlag = mockFeatureFlags.find((flag) => flag.id === id) ?? null;

  const [featureFlag, setFeatureFlag] = useState<FeatureFlag | null>(
    originalFeatureFlag ?? null,
  );

Ref: https://stackoverflow.com/questions/5076944/what-is-the-difference-between-null-and-undefined-in-javascript

[HakSooDev]

따로 destructure 안하고 아래처럼 해도 충분할것 같습니다.

 setFeatureFlag(originalFeatureFlag);

[HakSooDev]

컴포넌트 잘 나누신것 같습니다.

[HakSooDev]

function naming 이 다 좋아서 굳이 코멘트들은 없어도 괜찮을것 같습니다.
다 지우는게 좋을것 같습니다.

[HakSooDev]

newVariations 보다 updatedVariations 가 이해가 조금 더 빠르게 될것 같습니다.

[HakSooDev]

이 코멘트도 지워도 괜찮을것 같습니다.

[HakSooDev]

타입스크립트 공부 많이하셨군요.
as FeatureFlag['type'] 사용 잘 하신것 같습니다.

여기서 조금 UX 관련해서 타입이 바뀌면 variations 도 다 없애거나 default 값들로 리셋을 해야하지 않을까 생각이 드는데 일단 이건 급한건 아니니깐 하셔도 되고 안하셔도 괜찮습니다 .

[HakSooDev]

variation의 key는 유니크하니까, 여기에서 index보다 key를 사용하는 게 어떨까 생각이 드네요. 다만, 이렇게 할려면 add variation 시 key를 어떻게 유니크하게 생성할지, 그리고 UX적으로 어떻게 풀어낼지 고민해봐야 할 것 같아요.

[lsc2159]

variation의 key값을 UUID로 사용해볼까 생각을 해봤습니다. 혹시 몰라서 key값 부분은 아직 index로 나뒀습니다.

[HakSooDev]

variation의 key값을 UUID로 사용해볼까 생각을 해봤습니다. 혹시 몰라서 key값 부분은 아직 index로 나뒀습니다.

넵 좋습니다 일단 그 부분은 나중에 더 덧대기로 합시다.

[tjrmswo]

고생하셨습니다!