import "./styles.css"; import { useFormik } from "formik"; const formInitialValues = { regNoFront: "", regNoBack: "" }; export default function App() { // form의 validation을 확인하는 validator const validator = (values) => { let error = {}; // 에러객체가 있으면 handle submit이 되지 않는다. const { regNoFront, regNoBack } = values; console.log(regNoFront.length); if (regNoFront.length < 6) { error.regNoFront = "주민번..

Typo를 관리하는 컴포넌트. 테마에 지정해놓은 Typo의 값을 사용하는 것에만 집중했다. import React from "react"; import { WithChildrenAndStyle } from "../../../interfaces"; import { styled } from "../../../styles/Themes"; export interface Props extends WithChildrenAndStyle { ellipse?: boolean; type?: "body" | "head"; dp?: "block" | "inline" | "inline-block" | "flex"; ws?: "pre" | "no-wrap" | "pre-wrap"; s?: string; c?: string; } ..

최근 지인으로부터 css in js 에 대한 불만 아닌 불만을 들을 기회가 있었다. css, js, html이 각자 가지고 있는 역할이 분명히 다른데, (컴포넌트 위주의 웹 개발 환경이 득세하다보니) css in js등의 등장으로 그 역할이 모호해지고 있다는 것이다. 그 말에도 일리가 있다고 생각했다. 사실 구현의 측면에서는 그 역할이 사라지거나 불분명해지진 않았다. 하지만 컴포넌트 위주의 웹 개발에서는 html태그의 계층구조, 스크립트와 dom의 연결, bem등을 사용한 css클래스 네이밍 등의 작업에 많은 시간을 투자하지 않고 결과물을 낼 수 있게 된 것은 사실인 것 같다. css in js가 가지고 있는 성능상의 이슈도 있고, 기술에는 정답이 없다고 생각하는 만큼 이러한 추세가 앞으로 또 어떻게 변..

오랜만에 올리는 취미 개발이다. 사실 그 사이에 만든 다른 게 있긴 한데.... 그 포스팅은 좀 나중에 올리기로 하고 가장 최근에 일렉트론으로 만든 녹취록 작성기 얘기를 해보려고 한다. 처음 일렉트론 이야기를 듣게된 계기는 지인 개발자분의 언급이었다. 얼마 전, 한창 리액트를 공부하며 재미를 느끼고 나름 나름 스터디도 진행하던 도중이었다. "나중에 관심있으면 리액트로 윈도우 프로그램도 만들어보세요." "네?? 그런것도 가능해요?" "일렉트론이라고 node.js로 만들어진 프레임워크 있어요" "오오....!" 최근 크롬 확장프로그램을 리액트로 만들어 보면서 리액트 생태계의 확장성에 감탄을 마지않던 차였기 때문에 '조만간 일렉트론으로 뭐라도 한 번 만들어보고 만다'라고 단단히 벼르고 있었다. 그러던 중, 사..