📱 Webview

<img src="https://image.until.blog/morethanmin/article/1717424912994" alt="until-401"><p>디자인 시스템을 구현하면서 <code spellcheck="false">:hover</code> 가상 클래스를 적용했던 경험을 기록한다.</p><p><code spellcheck="false">:hover</code>는 포인터가 해당 엘리먼트 위에 올라가 있는 상태를 나타내는 가상 클래스로 주로 버튼이나 인풋과 같은 컴포넌트를 구현할 때 사용한다.</p><p>이러한 <code spellcheck="false">:hover</code> 가상 클래스는 마우스를 올려둔다와 같은 경우가 없는 환경에서는 어떻게 동작할까? 대표적으로 터치로 동작하는 모바일 디바이스가 있을 텐데, 어떻게 동작하는지 알아보자.</p><h1><strong>터치 디바이스에서의 :hover</strong></h1><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://developer.mozilla.org/ko/docs/Web/CSS/:hover">:hover</a> 페이지의 예제를 브라우저에서 실행시켜보면 쉽게 알 수 있다.</p><pre spellcheck="false"><code class="language-css">a:hover {
  background-color: gold;
}
</code></pre><p>PC 브라우저에서는 잘 동작하지만, 모바일 브라우저에서는 마우스 포인터가 없으니 <code spellcheck="false">:hover</code> 클래스가 동작하지 않을 것처럼 보이지만, 클릭 이벤트가 발생할 경우 <code spellcheck="false">:hover</code>에 선언한 배경 색상이 변경된 채로 남아있는다. 그리고 다른 영역을 클릭하면 효과가 해제된다는 것을 알 수 있다.</p><p>그렇다면 마우스 환경과 동일하게 <code spellcheck="false">touchOver</code> 시에만 스타일이 적용되게 하려면 어떻게 해야할까?</p><h1><strong>터치 디바이스에서 동일하게 스타일 적용하기</strong></h1><h2>@media hover</h2><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://developer.mozilla.org/en-US/docs/Web/CSS/@media/hover">@media hover</a>를 이용하면, hover를 지원하는 환경인 경우에만 해당 스타일이 적용되도록 할 수 있다.</p><p>예시는 아래와 같다.</p><pre spellcheck="false"><code class="language-css">a:hover { /* default hover effect */
  color: black;
  background: yellow;
}

@media (hover: hover) { /* when supported */
  a:hover {
    color: white;
    background: black;
  }
}
</code></pre><p>하지만 이방법을 사용하더라도 <strong>일부 Android </strong>에서는 길게 누를 때 호버링을 에뮬레이트하는 기능이 있어 hover를 지원하는 것으로 판단하는 경우가 있다.</p><p>이러한 경우에도 동일한 경험을 제공하기 위해서는 @media pointer를 사용하면된다.</p><h2><strong>@media pointer</strong></h2><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pointer">@media pointer</a>는 장치에 포인터의 존재 여부와 포인팅 장치의 정확도를 확인한다.</p><p>mdn에서는 아래와 같이 설명하고 있다. 우리의 경우에는 fine 을 사용하면 된다.</p><blockquote><p><code spellcheck="false">none</code></p><p>The primary input mechanism does not include a pointing device.</p><p><code spellcheck="false">coarse</code></p><p>The primary input mechanism includes a pointing device of limited accuracy, such as a finger on a touchscreen.</p><p><code spellcheck="false">fine</code></p><p>The primary input mechanism includes an accurate pointing device, such as a mouse.</p></blockquote><p>결과적으로 아래와 같이 적용하면 된다.</p><pre spellcheck="false"><code>@media (hover: hover) and (pointer: fine) { /* when supported */
  a:hover {
    color: white;
    background: black;
  }
}
</code></pre><p>호버를 지원하고, 포인터를 지원하는 디바이스인 경우에만 호버 스타일을 적용할 수 있게 되었다.</p><h1>결론</h1><p>결론적으로 위 방법을 사용하면 포인터를 사용하는 디바이스에서만 호버스타일을 적용할 수 있게되었지만, 위 방법이 무조건적으로 적합한 방식인지는 생각해볼 필요가 있다.</p><p>결국 터치디바이스에서 hover스타일을 적용시키고 있는 것이 지금의 웹 표준 동작에 가깝다고 할 수 있는 것이기 때문이다.</p>

디자인 시스템을 구현하면서 :hover 가상 클래스를 적용했던 경험을 기록한다.:hover는 포인터가 해당 엘리먼트 위에 올라가 있는 상태를 나타내는 가상 클래스로 주로 버튼이나 인풋과 같은 컴포넌트를 구현할 때 사용한다.이러한 :hover 가상 클래스는 마우스를 올려둔다와 같은 경우가 없는 환경에서는 어떻게 동작할까? 대표적으로 터치로 동작하는 모바일 디

터치 디바이스에서 hover 스타일 제어하기

프론트엔드

🖥 백엔드

<pre spellcheck="false"><code class="language-java">public class ArticleService {
    private final ArticleRepository articleRepository;
    private final UserRepository userRepository;

    public Article writeArticle(ArticleWriteRequest request) {
        // ...
    }
}</code></pre><p>Layered Architecture와 함께 Spring으로 서비스를 구현하다보면 필연적으로 Repository 의존성이 생기게 된다. 그리하면 당연히 서비스의 테스트를 짜기 위해서는 Repository의 의존성을 주입해주어야 한다.</p><p></p><pre spellcheck="false"><code class="language-java">class ArticleServiceTest {
    @Test
    void writeArticleTest() {
        // given
        ArticleRepository repository = mock(ArticleRepository::class);
        when(repository.save(any())).thenReturn(
            Article.builder()
                .id(1)
                .title("title")
                .content("content")
                .build()
        );

        ArticleService articleService = new ArticleService(
            repository,
            mock(UserRepository::class)
        );
        
        // when
        articleService.writeArticle(
            new ArticleWriteRequest("title", "content")
        );

        // then
        assertThat(repository.findAll()).hasSize(1);
        assertThat(repository.findById(1).getTitle()).isEqualTo("title");
    }
}</code></pre><p>하지만 서비스의 테스트를 하기 위해 매번 <code spellcheck="false">@SpringBootTest</code>를 할 수 없는 노릇이고, 매번 이렇게 모킹을 할 경우 매번 <code spellcheck="false">when</code>을 통해 Repository의 동작을 작성해주어야 하므로 실제로 Service가 제대로 동작하는지를 확인하기 조금 까다롭다.</p><p></p><pre spellcheck="false"><code class="language-java">public class ArticleMockRepository implements ArticleRepository {
    private final Map&lt;Long, Article&gt; articleMap = new HashMap&lt;&gt;();

    public Article save(Article a) {
        articleMap.put(a);
        return a;
    }
    
    public Optional&lt;Article&gt; findById(long id) {
        return Optional.ofNullable(articleMap .get(id));
    }

    public List&lt;Article&gt; findAll() {
        return List.copyOf(articleMap.values());
    }

    public void clear() {
        map.clear();
    }
}</code></pre><p>그렇기 때문에 나는 Stub을 통해 진짜 객체를 넣어주는 것을 선호한다. 레포지토리는 HashMap을 통해 구현할 수 있으니!</p><p>하지만 Repository는 비즈니스 객체의 갯수만큼 존재할 것이고, 이걸 매번 다 짜려면 굉장히 귀찮은데.</p><p>그러니 제네릭을 활용하여 공통화를 해보자.</p><p></p><h1>제네릭을 사용해 공통화하기</h1><pre spellcheck="false"><code class="language-java">public class HashMapRepository&lt;T&gt; {
    private final Map&lt;Long, T&gt; map = new HashMap&lt;&gt;();

    protected void save(long id, T entity) {
        map.put(id, entity);
    }

    public Optional&lt;T&gt; findById(long id) {
        return Optional.ofNullable(map.get(id));
    }

    public List&lt;T&gt; findAll() {
        return List.copyOf(map.values());
    }

    // 원하는 조회 조건 생성용
    protected Optional&lt;T&gt; findBy(Predicate&lt;T&gt; predicate) {
        return map.values().stream()
                .filter(predicate)
                .findFirst();
    }

    protected List&lt;T&gt; findAllBy(Predicate&lt;T&gt; predicate) {
        return map.values().stream()
                .filter(predicate)
                .toList();
    }

    public void clear() {
        map.clear();
    }
}</code></pre><p>다음과 같이 <code spellcheck="false">HashMapRepository</code>를 구현할 수 있다. 이렇게 구현한다면 이제 각 도메인 별로 레포지토리를 만들기는 간단하다.</p><p></p><pre spellcheck="false"><code class="language-java">class ArticleMockRepository extends HashMapRepository&lt;Article&gt; implements ArticleRepository {
    @Override
    public Article save(Article article) {
        super.save(article.getId(), article);
        return article;
    }

    @Override
    public Optional&lt;Article&gt; findByAuthorId(long authorId) {
        return findBy(it -&gt; it.getAuthorId() == authorId);
    }
}</code></pre><p>다음과 같이 <code spellcheck="false">save</code>만 재정의해주면 된다.</p><p>만약 원하는 조회 조건이 필요하다면, <code spellcheck="false">findBy</code>, <code spellcheck="false">findAllBy</code>를 이용해서 원하는 조건을 <code spellcheck="false">Predicate </code>로 넣어주는 방식을 이용해서 추가해주면 된다.</p><p></p><h1>적용과 함께 마무리</h1><pre spellcheck="false"><code class="language-java">class ArticleServiceTest {
    @Test
    void writeArticleTest() {
        // given
        ArticleRepository repository = new ArticleMockRepository();

        ArticleService articleService = new ArticleService(
            repository,
            new UserMockRepository()
        );
        
        // when
        articleService.writeArticle(
            new ArticleWriteRequest("title", "content")
        );

        // then
        assertThat(repository.findAll()).hasSize(1);
        assertThat(repository.findById(1).getTitle()).isEqualTo("title");
    }
}</code></pre><p>꽤나 깔끔한 모양새로 테스트를 작성할 수 있게 됐다.</p><p></p><h1>구현해야 할 메소드가 너무 많아요</h1><img src="https://image.until.blog/octoping/article/1730861041484.png" data-width="75%" data-align="center" alt="1985"><p>이런 식으로 Stub 객체를 만드려고 했더니 <code spellcheck="false">ArticleRepository</code> 안의 인터페이스가 너무 많아서 모두 구현하기 힘들 수도 있다. ( <code spellcheck="false">JpaRepository</code> 를 그대로 상속받아서 사용 중인 경우 특히 그렇다)</p><p>하지만 그렇다고 Stub을 포기하고 Mock을 시도하는 것은, 테스트 코드가 알려주는 코드 악취를 모킹이라는 강력한 도구로 감추고 숨는 것에 지나지 못한다.</p><p>그럴 때에는 설계를 조금 고쳐보는 것은 어떨까? 이전 블로그의 글을 링크 걸어본다.</p><a data-type="bookmark" href="https://octoping.tistory.com/27" target="_blank"><div class="content"><div><div class="title">Service 계층에 적당한 무게의 Repository 의존성 지우기</div><div class="description">시작하기 전에 계층형 아키텍처에서 개발을 진행할 때 우리는 보통 Controller, Service, Repository 이렇게 3개의 계층의 구조로 짜게 된다. 이 3개의 계층은 Controller에서 Service로, Service에서 Repository로 의존성이 흐르는데, 이 중에서도 Repository 부분을 보통 JpaRepository나 Mybatis mapper 같은 클래스로 직접 의존성으로 사용하는 경우가 많다. 하지만 Service 계층에서 바로 이런 클래스들에 의존하게 될 경우 몇 가지 문제가 생기게 된다. 이 글에서는 쉬운 예제 작성을 위해 JpaRepository를 사용하겠다. Service에서 바로 JpaRepository를 의존할 때 생기는 문제 Service 계층이 세부 사항..</div></div><div class="href">https://octoping.tistory.com/27</div></div><img src="https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&amp;fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdoLA4o%2Fbtr91zZpY94%2FcfEYJzMiizQCm0JDnuHq31%2Fimg.png"></a>

반복되는 Repository Stub 코드 줄이기