피드 신고 기능 구현 #285
피드 신고 기능 구현 #285
Conversation
| @Operation(summary = "신고 사유 목록 조회", description = "신고 사유 목록을 가져옵니다.") | ||
| @GetMapping("/reasons") | ||
| public ResponseEntity<List<ReportReasonResponse>> getReportReasons() { | ||
| List<ReportReasonResponse> reasons = reportService.getReportReasons(); | ||
| return ResponseEntity.ok(reasons); | ||
| } | ||
|
|
There was a problem hiding this comment.
굳이 reasons 엔드포인트를 작성하지 않아도 /reports 만으로 충분해보입니당
|
|
||
| Report report = | ||
| Report.builder() | ||
| .missionRecord(missionRecord) | ||
| .member(member) | ||
| .reportReason(reportReason) | ||
| .details(reportRequest.details()) | ||
| .build(); |
There was a problem hiding this comment.
도메인 entity에서 정적 팩토리 메서드를 사용하면 좋을 거 같아용
제가 comment 엔티티에 적용했듯이 사용하면 좋을 듯 합니당
| // report | ||
| INVALID_REPORT_REASON(HttpStatus.NOT_FOUND, "해당 신고 목록을 찾을 수 없습니다."); | ||
| private final HttpStatus httpStatus; |
There was a problem hiding this comment.
신고 목록보다는 신고 사유를 찾을 수 없습니다.가 맞지 않을까용???
|
|
||
| @Builder | ||
| private Report(MissionRecord missionRecord, Member member, String reason, String details) { | ||
| this.missionRecord = missionRecord; | ||
| this.member = member; | ||
| this.reason = reason; | ||
| this.details = details; | ||
| } |
There was a problem hiding this comment.
Builder 패턴을 외부에서 사용하지 못하도록
@Builder(access = AccessLevel.PRIVATE)으로 변경부탁드릴게용
|
|
||
| private String reason; | ||
|
|
There was a problem hiding this comment.
@Enumerated(EnumType.STRING) 사용해서 Enum 타입으로 정의하지 않는 이유가 있을까용??
There was a problem hiding this comment.
EnumType.STRING을 사용하면 db에 enum의 name값이들어가서 convert를 사용하거나 String을사용해서 value를 저장하려했습니다. 혹시 좋은 방법이 있을까요
There was a problem hiding this comment.
아니면 이건 기획 의도따라 다르겠지만 굳이 ReportReason을 enum으로 정의하지 않고,
일반적인 String 값으로 받는 건 어떨까요??
신고하려는 이유가 너무 불특정하게 계속 생길 수도 있고, enum에 대한 길이도 계속 길어지다보니 굳이 enum 자체를 Request 받지 않고 String으로 Request 받아도 될 듯해용
There was a problem hiding this comment.
음.. figma를 봤을 땐 기획상 신고 사유가 많아지더라도 지금 수준이랑 비슷할 것 같다고 생각했어요! 그리고 기타라는 항목도 있기에 크게 이유가 불특정하게 enum값이 생길 것 같다고 생각을 안했습니다.
저는 Enum을 사용해서 관리하는 부분이 좀 더 낫다고 생각하는데 어떻게 생각하시나요?
추가로 현재는 Enum을 name-value형식으로 되어있는데 @convert를 사용해서 Enum을 사용하되, 원하는 value값을 저장하는 방식으로 코드를 수정하는건 어떨까요?
There was a problem hiding this comment.
위의 댓글 취소!,,, 윤범님이 말씀하신대로 클라이언트한테 request를 String으로받고 하는식으로 진행하도록 하겠습니다.
There was a problem hiding this comment.
수정된 부분 확인한번 부탁드릴게요~
| @Operation(summary = "신고하기", description = "특정 피드를 신고한다.") | ||
| @PostMapping | ||
| public ResponseEntity<Void> reportFeed(@RequestBody ReportRequest reportRequest) { | ||
| reportService.reportFeed(reportRequest); | ||
| return ResponseEntity.ok().build(); | ||
| } | ||
| } |
There was a problem hiding this comment.
사실 예전부터 컨벤션 정의할 때부터 맞췄어야 했는데 Entity Resource 생성 시 ResponseEntity 201 Status Code로 return 하도록 하는 것이 가독성 측면과 RestFul하다고 하더라고용
|
🌱 관련 이슈
📌 작업 내용
🙏 리뷰 요구사항
📚 레퍼런스