Conversation
MovieBooking/Config/Realse.xcconfig
Outdated
|
|
||
| OTHER_SWIFT_FLAGS[config=PROD][sdk=*] = $(inherited) -PROD | ||
| SWIFT_ACTIVE_COMPILATION_CONDITIONS = PROD | ||
| BUNDLE_DISPLAY_NAME = 책시리즈 |
There was a problem hiding this comment.
잘못 들어간거여서 제거 했습니다
| static var megaboxPrimary: Color { .init(hex: "503396") } | ||
| static var megaboxViolet: Color { .init(hex: "9333EA") } |
There was a problem hiding this comment.
megabox 클론 앱은 아니니까 megabox 대신 다른 명칭을 쓰는건 어떤가요??
MovieBooking/App/Di/DIRegistry.swift
Outdated
|
|
||
| /// Repository 등록 | ||
| static func registerRepositories() async { | ||
| let repositories: [ Module] = [ |
Peter1119
left a comment
There was a problem hiding this comment.
고려해볼사항이 있어서
의견 나눠 보거나 혹은 수정 되면 다시 말씀해주세요 ~!
| 🪛[chore]: 코드 수정, 내부 파일 수정. </br> | ||
| ✨[feat]: 새로운 기능 구현. </br> | ||
| 🎨[style]: 스타일 관련 기능.(코드의 구조/형태 개선) </br> | ||
| ➕[add]: Feat 이외의 부수적인 코드 추가, 라이브러리 추가 </br> | ||
| 🔧[file]: 새로운 파일 생성, 삭제 시 </br> | ||
| 🐛[fix]: 버그, 오류 해결. </br> | ||
| 🔥[del]: 쓸모없는 코드/파일 삭제. </br> | ||
| 📝[docs]: README나 WIKI 등의 문서 개정. </br> | ||
| 💄[mod]: storyboard 파일,UI 수정한 경우. </br> | ||
| ✏️[correct]: 주로 문법의 오류나 타입의 변경, 이름 변경 등에 사용합니다. </br> | ||
| 🚚[move]: 프로젝트 내 파일이나 코드(리소스)의 이동. </br> | ||
| ⏪️[rename]: 파일 이름 변경이 있을 때 사용합니다. </br> | ||
| ⚡️[improve]: 향상이 있을 때 사용합니다. </br> | ||
| ♻️[refactor]: 전면 수정이 있을 때 사용합니다. </br> | ||
| 🔀[merge]: 다른브렌치를 merge 할 때 사용합니다. </br> | ||
| ✅ [test]: 테스트 코드를 작성할 때 사용합니다. </br> |
There was a problem hiding this comment.
이거 이전부터 궁금했는데
이건 자동으로 불러올 수 있는건가요 ?
아니면 가이드 같은건가요 ?
There was a problem hiding this comment.
@Peter1119 가이드 입니다 불러올수도 있는데 제가 예전에 했는데 그건 나중에 설명 드릴께요 제 fork 에서는 자동으로 되게 설정 해 놓아서요!
| /* Begin PBXBuildFile section */ | ||
| 7F6F8B432E9D27850046FA0E /* Auth in Frameworks */ = {isa = PBXBuildFile; productRef = 7F6F8B422E9D27850046FA0E /* Auth */; }; | ||
| 7F6F8B452E9D27850046FA0E /* Supabase in Frameworks */ = {isa = PBXBuildFile; productRef = 7F6F8B442E9D27850046FA0E /* Supabase */; }; | ||
| 7F6F8B482E9D279B0046FA0E /* WeaveDI in Frameworks */ = {isa = PBXBuildFile; productRef = 7F6F8B472E9D279B0046FA0E /* WeaveDI */; }; |
There was a problem hiding this comment.
저희 DI 넣는거 고민한번 해보면 좋을 것 같아요
단일 레포라 꼭 필요할까 싶은 생각이 있습니다 ~!
이건 의견 나눠봐도 좋을 것 같아요 ~!
There was a problem hiding this comment.
@Peter1119 어차피 단일 레포여도 그렇긴 한데 클린아키텍쳐 및 그걸 생각 했을때는 저는 di넣어도 될거 같은데 같이 의견 나누어봐요!
| public extension ShapeStyle where Self == Color { | ||
| static var basicPurple: Color { .init(hex: "503396") } | ||
| static var violet: Color { .init(hex: "9333EA") } | ||
| static var brightYellow: Color { .init(hex: "FEE500") } | ||
| } |
There was a problem hiding this comment.
이전에 리뷰 남겼었는지 궁금한데
이렇게 넣으면 다크모드 대응은 어떻게 하나요 ?
뷰에서 감지해서 색상을 설정해줘야하나요 ?
만일 그렇다면 이미지 에셋이 더 편리하지 않은가 싶은 생각입니다 ~!
There was a problem hiding this comment.
전 이미지 에셋이 무겁다고 느끼고 저희가 지금은 다크 모드는 대응을 안하닌 괜찬을거 같습니다
다크모드 일경우도 저 생삭 같은경우는 다크 모드 까지는 필요없다고 느낌니다 @Peter1119
| struct PretendardFont: ViewModifier { | ||
| public let family: PretendardFontFamily | ||
| public let size: CGFloat | ||
|
|
||
| public func body(content: Content) -> some View { | ||
| return content.font(.custom("PretendardVariable-\(family)", fixedSize: size)) | ||
| } | ||
| } |
There was a problem hiding this comment.
제가 알기론 modifier를 너무 많이 쓰면 성능상 좋지 않다고 해서
font의 extension으로만 참조해도 충분하지 않을까요 ?
| private func handleViewAction( | ||
| state: inout State, | ||
| action: View | ||
| ) -> Effect<Action> { | ||
| switch action { | ||
|
|
||
| } | ||
| } | ||
|
|
||
| private func handleAsyncAction( | ||
| state: inout State, | ||
| action: AsyncAction | ||
| ) -> Effect<Action> { | ||
| switch action { | ||
|
|
||
| } | ||
| } | ||
|
|
||
| private func handleNavigationAction( | ||
| state: inout State, | ||
| action: NavigationAction | ||
| ) -> Effect<Action> { | ||
| switch action { | ||
|
|
||
| } | ||
| } | ||
|
|
||
| private func handleInnerAction( | ||
| state: inout State, | ||
| action: InnerAction | ||
| ) -> Effect<Action> { | ||
| switch action { | ||
|
|
||
| } | ||
| } |
There was a problem hiding this comment.
우선 사용하지 않는다면 없어지는것도 깔끔할 것 같습니다 ~! 필요할때 추가하는 방식으로요 !
| import ComposableArchitecture | ||
|
|
||
| struct SplashView: View { | ||
| @Bindable var store: StoreOf<Splash> |
There was a problem hiding this comment.
혹시 binding 되는 상태값이 없는 것 같은데 그럼 bindable하지 않아도 되지 않을까요 ?
| .opacity(store.fadeOut ? 0.0 : 1.0) | ||
| .animation(.easeInOut(duration: 1), value: store.fadeOut) | ||
| .onAppear { | ||
| store.send(.view(.onAppear)) |
There was a problem hiding this comment.
view action 정의 되어있는데 처리되지 않고 있는 것 같습니다 ~!
There was a problem hiding this comment.
https://mehmetbaykar.com/posts/tca-tips-the-power-of-viewactions/
여기 링크 확인해보시겠어요 ?
| @CasePathable | ||
| public enum View : Equatable{ | ||
| case onAppear | ||
| case startAnimationSequence |
There was a problem hiding this comment.
startAnimation
이렇게 간단하게 해도 의미는 통할 것 같아요 ~!
|
|
||
|
|
||
| @Reducer | ||
| public struct Splash { |
There was a problem hiding this comment.
네이밍에 대한 생각을 같이 해보면 좋을 것 같은데
Splash, Login 과 같이 이름을 가져가면
Entity 정의할때 겹칠 것같아요
Movies, MovieList, MovieDetail 처럼요 ~!
저는 뒤에 Feature를 붙히는 것을 선호하는데 어떻게 생각하시나요 ?
There was a problem hiding this comment.
@Peter1119 저도 처음에는 feature 를 쓰었는데 reducer 로 통일 해도 괘찮을거 같습니다 이건 한번 의견을 나누어 보면 좋을거 같아요!
| @Reducer | ||
| struct AppReducer { | ||
|
|
||
| @ObservableState | ||
| enum State { | ||
| case splash(Splash.State) | ||
| case auth(AuthCoordinator.State) | ||
|
|
||
|
|
||
|
|
||
| init() { | ||
| self = .splash(.init()) | ||
| } | ||
| } | ||
|
|
||
| enum Action: ViewAction { | ||
| case view(View) | ||
| case scope(ScopeAction) | ||
| } |
There was a problem hiding this comment.
App도 Reducer가 아닌 AppCoordinator로 할 수 있지 않을까요 ??
There was a problem hiding this comment.
@Peter1119 흠 저건 좀 고민 해볼께요! 전 reeucer 하는게 더 낳다고 생각 이들어서요!
어자피 각 씬에 코디네이터가 있는데 굳이 앱까지 필요할까라고 생각듭니다
🔗 관련 이슈
✨ 작업 내용
📸 Showcase
Close Issues 🔒 (닫을 Issue)
Close #1, #2