IoC 컨테이너는 Bean 라이프 사이클을 관리하여 주고 특정한 시점에 Bean에게 이를 알려줄수 있는 메커니즘을 제공합니다. 스프링에서는 주로 init와 destroy 이벤트를 제공합니다.

InitializingBean와 DisposableBean 인터페이스

InitializingBean 인터페이스를 활용해서 Bean의 초기화 작업을 진행할수 있습니다. 해당 인터페이스에서 제공하는 afterPropertiesSet메소드를 구현하면 Spring이 Bean의 생성 후에 해당 메소드를 호출해 줍니다.

1
2
3
4
5
6
7
8
9
10
@Component
public class Book implements InitializingBean {
@Autowired
BeanFactory beanFactory;

public void afterPropertiesSet() throws Exception {
System.out.println("Bean이 등록되었습니다.");
System.out.println(beanFactory.getBean("book"));
}
}
1
2
Bean이 등록되었습니다.
kr.co.spring.Book@3745e5c6

DisposableBean 인터페이스에서 제공하는 destroy메소드를 구현하면 Bean의 소멸 직전에 해당 메소드를 호출해 줍니다.

1
2
3
4
5
6
7
8
9
10
11
@Component
public class Book implements DisposableBean {

@Autowired
BeanFactory beanFactory;

public void destroy() throws Exception {
System.out.println("Bean이 삭제됩니다..");
System.out.println(beanFactory.getBean("book"));
}
}

xml 빈 등록시 사용자 라이프사이클 메소드 정의

xml에서 빈을 수동으로 등록시에 위의 InitializingBean, DisposableBean을 사용하지 않고 사용자 메소드를 정의 가능합니다.

1
<bean id="book" class="kr.co.spring.Book" init-method="initBook" destroy-method="destroyBook"/>
1
2
3
4
5
6
7
8
9
public class Book {
public void initBook() {
System.out.println("빈이 등록되었습니다.");
}

public void destoryBook() {
System.out.println("빈이 삭제되었습니다.");
}
}

@PostConstruct와 @PreDestroy

좀 더 간편하게 어노테이션을 이용해서 위와 동일하게 사용할수 있습니다.

@PostConstruct는 Bean이 생성 된 후에 호출 될 메소드 위에 사용합니다.

1
2
3
4
5
6
7
8
9
10
11
@Component
public class Book {
@Autowired
BeanFactory beanFactory;

@PostConstruct
public void init() throws Exception {
System.out.println("Bean이 등록되었습니다.");
System.out.println(beanFactory.getBean("book"));
}
}
1
2
Bean이 등록되었습니다.
kr.co.spring.Book@644baf4a

@PreDestroy는 Bean이 소멸 직전에 호출 될 메소드 위에 사용합니다.

1
2
3
4
5
6
7
8
@Component
public class Book {

@PreDestroy
public void destroy() throws Exception {
System.out.println("빈이 삭제되었습니다.");
}
}

기타

ApplicationContext 클래스도 Bean으로 등록되어 있기 때문에 의존주입 받을수 있습니다. 이 뿐 아니라 ApplicationContext가 상속하고 있는 BeanFactory, ResourceLoader 등도 Bean으로 등록되어 있기 때문에 ApplicationContext를 의존주입 받지 않고 필요한 기능을 가진 Bean을 의존주입해서 사용하는 것이 가시성에 좋습니다(ex : Bean과 관련된 처리를 할때는 BeanFactory사용).

Comment and share

예제 소스 코드
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<!-- BookStore.class -->

public interface BookStore {

}

<!-- NobleBookStore.class -->

@Service
public class NobleBookStore implements BookStore {

}

<!-- EssayBookStore.class -->

@Service
public class EssayBookStore implements BookStore {

}

중복된 의존주입

동일한 타입의 Bean을 의존 주입 받으려고 하면 문제가 발생합니다(동일한 타입의 Bean 등록에는 문제가 없다).

1
2
3
4
5
6
7
8
9
@Component
public class City {
@Autowired
BookStore bookStore;

public BookStore getBookStore() {
return bookStore;
}
}
1
Error creating bean with name 'city': Unsatisfied dependency expressed through field 'bookStore'

동일한 타입의 Bean이 2개가 존재하기 때문에 위와 같은 에러가 발생합니다.


해결방법

@Primary 어노테이션 사용

우선적으로 의존 주입하고 싶은 class에 @Primary 어노테이션을 사용합니다.

1
2
3
4
5
@Service
@Primary
public class NobleBookStore implements BookStore {

}
1
2
3
4
5
6
7
8
9
public class TestControllerTest {

@Test
public void test() {
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeanConfig.class);
System.out.println(((City)applicationContext.getBean("city")).getBookStore());

}
}
1
kr.co.spring.NobleBookStore@16e7dcfd

@Qulifier 어노테이션 사용

@Autowired와 함께 사용하며 사용하고자 하는 빈의 아이디를 적어주면 됩니다(빈의 아이디를 따로 설정하지 않으면 default로 class 명에 첫글자가 소문자인 아이디로 설정된다).

1
2
3
4
5
6
@Component
public class City {
@Autowired
@Qualifier("nobleBookStore")
BookStore bookStore;
}

@Qulifier 어노테이션 사용하지 않기

기본적으로 @Autowried는 타입으로 의존주입을 해주지만 타입이 존재하지 않으면 Bean Name으로도 의존주입이 가능합니다. 그래서 굳이 @Qulifier를 사용하지 않아도 사용이 가능합니다.

아래의 코드를 보면 이해가 가능합니다.

1
2
3
4
5
@Component
public class City {
@Autowired
BookStore nobleBookStore; // 기존에 bookStore 대신 nobleBookStore를 사용하과 있다.
}

동일한 타입의 Bean 모두 의존주입 받기

동일한 타입의 Bean들을 모두 의존주입을 받을수가 있습니다.

1
2
3
4
5
@Component
public class City {
@Autowired
List<BookStore> bookRepoitories;
}

Comment and share

@Autowried는 Bean으로 등록된 객체를 자동으로 삽입해주는 역할을 합니다. 생성자, 필드, set메소드를 활용 하여 적용이 가능합니다.

예제 Class 등록

해당 포스팅 시에 사용 할 Book 클래스입니다. 아래에서 사용 될 Book 클래스는 아래 소스 코드를 사용하게 됩니다.

1
2
3
4
5
6
7
8
package kr.co.spring;

import org.springframework.stereotype.Component;

@Component
public class Book {

}

생성자를 이용한 방법

생성자 메소드 위에 @Autowired만 등록 해서 사용 하면 됩니다.

1
2
3
4
5
6
7
8
9
@Component
class BookStore {
private Book book;

@Autowired
public BookStore(Book book) {
this.book = book;
}
}

생성자에서 @Autowired는 생략이 가능합니다.


setter를 이용한 방법

setter 메소드 위에 @Autowired만 등록 해서 사용 하면 됩니다. 생성자와는 달리 @Autowired를 붙여주지 않으면 의존주입이 되지 않습니다.

1
2
3
4
5
6
7
8
9
@Component
class BookStore {
private Book book;

@Autowired
public setBook(Book book) {
this.book = book;
}
}

setter를 활용하면 Bean을 필수적으로 의존주입 받을지 여부를 선택할수 있습니다. 옵션을 주지 않는 경우 의존주입 받을 Bean이 없는 경우 에러가 발생합니다. 이때 @Autowired(required = false)를 사용해서 만약 Bean이 존재하지 않는 경우 의존주입을 받지 않도록 설정이 가능합니다.

setter 메소드 이름은 상관이 없습니다.


필드에 직접 사용

필드 위에 @Autowired를 등록해서 사용이 가능합니다. 가장 심플하게 코드를 작성할수 있습니다. setter와 마찬가지로 required 옵션을 사용가능합니다.

1
2
3
4
5
@Component
class BookStore {
@Autowired
private Book book;
}
외부 라이브러리를 Bean 등록하고 의존주입

수정이 불가능한 외부라이브러리를 Bean으로 등록하고 해당 Bean에 의존주입까지 해주어야 하는 경우가 있습니다.

1
2
3
4
<bean id="library" class="kr.co.spring.Library">
<constructor-arg value="라이브러리"/>
<property name="location" value="서울"/>
</bean>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class Library {
private String name;
private String location;

public Library(String name) {
this.name = name;
}

public void setLocation(String location) {
this.location = location;
}

@Override
public String toString() {
return "Library{" +
"name='" + name + '\'' +
", location='" + location + '\'' +
'}';
}
}
1
2
3
4
5
6
7
8
9
public class TestControllerTest {

@Test
public void test() {
ApplicationContext applicationContext = new ClassPathXmlApplicationContext("spring/spring-bean.xml");
Library library = (Library) applicationContext.getBean("library");
System.out.println(library.toString());
}
}
1
Library{name='라이브러리', location='서울'}

만약 생성자에서 파라미터를 여러개 받는 경우에는 index를 이용하면 됩니다.

1
2
3
4
5
6
7

<bean id="library" class="kr.co.spring.Library">
<constructor-arg index="0" value="1"/>
<constructor-arg index="1" value="라이브러리"/>

<property name="location" value="서울"/>
</bean>

type 속성을 이용해서도 사용 가능합니다.

1
2
3
4
5
6
<bean id="library" class="kr.co.spring.Library">
<constructor-arg value="1" type="int"/>
<constructor-arg value="라이브러리" type="java.lang.String"/>

<property name="location" value="서울"/>
</bean>

예제에서는 value를 사용하였지만 bean을 의존주입 받을 때는 ref를 사용하면 됩니다.

Comment and share

IoC란

Ioc란 Inversion of Control의 약자로써, 어떤 객체가 사용하는 의존 객체를 직접 만들어 사용하는게 아니라 주입받아서 사용하는 방법을 일컫는 말입니다.

스프링 IoC 컨테이너

컨테이너는 보통 인스턴스의 생명주기를 관리하며, 생성된 인스턴스에게 추가적인 기능을 제공하는 것입니다. 스프링 컨테이너는 어플리케이션 컴포넌트의 중앙 저장소와 같은 역할을 하며 빈 설정 소스로부터 빈 정의를 읽어 들여 빈을 구성 하고 제공하는 역할을 합니다.

IoC 컨테이너의 핵심적인 역할을 하는 인터페이스가 BeanFactory이다.

IoC 컨테이너의 장점

  1. 의존주입을 통한 빈 관리가 용이하다.
  2. 싱글톤 사용을 할수 있다.
  3. 라이프사이클 인터페이스를 제공해준다.
    • @PostConstruct : 메소드 위에 사용하면 빈이 생성될때 실행된다(ApplicationContext에서 제공).
  4. 의존주입 방법을 통해서 테스트 하기 쉬운 코드를 작성할수 있다.
    • Mock 객체를 생성해서 의존성 주입을 할수 있어 테스트 하기에 용의하다.

Bean

스프링 IoC 컨테이너가 관리하는 객치입니다.

Bean 등록방법

1. XML을 이용한 방법

bean이라는 태그를 이용해서 Bean 등록을 할수 있다.

1
<bean id="인스턴스명" class="클래스경로"/>

옵션
  1. id : 보통 카멜케이스로 작성을 하며 사용할 인스턴스명을 입력해주면 된다.
  2. class : Bean 등록 하려는 클래스의 경로를 입력해주면 된다.
  3. scope : 말그대로 스코프를 설정
    • 기본값은 싱글톤
    • 매번 다른 값을 사용하려면 prototype으로 설정
    • 이외에도 request, session 등이 존재
  4. autowire

의존주입

property 태그를 이용해서 의존주입 관계를 형성 할수 있습니다. name은 의존주입할 set메소드 이름이고, ref는 Bean의 id입니다. 인스턴스가 아닌 경우 ref 대신 value를 사용합니다.

1
2
3
4
<bean id="book" class="kr.co.Book"/>
<bean id="store" class="kr.co.Store">
<property name="set메소드이름" ref="의존주입할 Bean의 id"/>
</bean>
1
2
3
4
5
6
7
class Store {
private Book book;

public void setBookTest(Book book) { // property의 name으로 bookTest를 입력해주어야 함
this.book = book;
}
}

property의 name의 값으로 입력해야 하는 것은 set메소드의 이름이다. set메소드의 인자의 이름이 아니다. 위의 코드로 예를 들면 bookTest를 입력해주어야 한다.


예제 코드
  • java
  • xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<!-- Test.class -->

public class Test {
public void test() {
System.out.println("너는 안녕?");
}
}

<!-- TestController.class -->

public class TestController {
private Test test;


public void test() {
System.out.println("안녕하세요");
test.test();
}

public void setTest(Test test) {
this.test = test;
}
}

테스트 코드를 통해서 XML 빈 등록이 잘 되고 있음을 확인할수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class TestControllerTest {

@Test
public void test() {
ApplicationContext applicationContext =
new ClassPathXmlApplicationContext("spring/spring-bean.xml");

TestController testController =
(TestController) applicationContext.getBean("testController");

testController.test();
System.out.println("등록 된 Bean" + Arrays.toString(applicationContext.getBeanDefinitionNames()));
}
}
1
등록 된 Bean[test, testController]

// 클래스 패스로 ApplicationContext 생성 (다른 방법도 존재)
ApplicationContext context = new ClassPathXmlApplicationContext(“클래스패스경로”);
context.getBeanDefinitionNames(); // 등록된 모든 Bean Name확인
context.getBean(“빈Name”); // Bean 가져오기


단점

XML로 작성하는 경우에는 문자열로 작성을 하기 때문에 자동완성기능 등 IDE의 도움을 받는 것에 제한이 되기 때문에 작성하는데에 어려움이 존재 합니다(지원 되는 것도 존재하지만 그래도 자바소스 작성시보다는 불편하다).


component-scan

지금까지는 수동으로 Bean을 등록을 하였었는데 이 방법으로는 수많은 Bean들을 직접 등록하기가 힘듭니다. 그래서 어노테이션을 통해서 좀더 간편하게 Bean등록하는 방법인 component-scan이 등장하게 되었습니다. package를 설정하여 해당 package내에서 @Component 어느테이션이 등록 된 객체를 Bean에 등록해 줍니다.

@Controller, @Service, @Repository 등 @Component 어노테이션을 상속한 어노테이션 또한 자동으로 등록 됩니다.


예제 코드
  • java
  • xml
1
2
3
4
5
6
7
8
package kr.co.spring;

import org.springframework.stereotype.Component;

@Component
public class ComponentScanTest {

}
1
2
3
4
5
6
7
8
9
10
public class TestControllerTest {

@Test
public void test() {
ApplicationContext applicationContext =
new ClassPathXmlApplicationContext("spring/spring-bean.xml");

System.out.println("등록 된 Bean" + Arrays.toString(applicationContext.getBeanDefinitionNames()));
}
}
1
등록 된 Bean[componentScanTest, ...]

클래스 설정파일로 Bean 등록

Spring 3.0 이후 보전부터 자바 소스 코드로도 Bean을 등록 할수 있는 방법이 추가 되었습니다. 자바 소스 코드로 작성하게 되면 IED의 기능을 활용할수 있기 때문에 XML보다 작성이 용이하다는 장점이 있습니다.

자바소스로 Bean 구성방법은 @Configuration과 @Bean으로 쉽게 구성이 가능합니다. @Configuration은 해당 클래스가 설정파일임을 명시해 줍니다. @Bean은 메소드 정의시에 사용하며 해당 메소드가 반환한 객체를 Bean으로 등록해줍니다. default로 메소드이름이 Bean Name이 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Configuration
public class BeanConfig {

@Bean
public Test test() {
return new Test();
}

@Bean
public TestController testController(Test test) {
TestController testController = new TestController();
testController.setTest(test);
return testController;
}
}
1
2
3
4
5
6
7
8
9
10
public class TestControllerTest {

@Test
public void test() {
ApplicationContext applicationContext =
new AnnotationConfigApplicationContext(BeanConfig.class); // 클래스설정파일로 Bean등록할때 사용하는 ApplicationContext
System.out.println("등록 된 Bean" + Arrays.toString(applicationContext.getBeanDefinitionNames()));

}
}
1
등록 된 Bean[..., test, testController]

@Bean을 활용한 DI에는 2가지 방법이 존재 합니다.

  1. 파라미터로 Bean 등록 된 객체를 작성하면 자동으로 주입해 줍니다(위의 방법).
  2. @Bean을 사용하는 메소드를 호출합니다(이 방법은 같은 클래스 내부에 존재할때만 가능).

클래스 설정파일로 component-scan

@Bean을 이용하는 방법 또한 직접 작성을 해야하기 때문에 등록하기가 힘듭니다. XML에서 compoennt-scan을 사용하였듯이 클래스 설정파일에서도 마찬가지로 component-scan을 사용할수 있습니다.

@ComponentScan(“base 패키지명”)으로 설정파일에 작성해주면 사용이 가능합니다.

1
2
3
4
5
@Configuration
@ComponentScan("kr.co.spring")
public class BeanConfig {

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Component
public class ComponentScanTest {

}


public class TestControllerTest {

@Test
public void test() {
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeanConfig.class);
System.out.println("등록 된 Bean" + Arrays.toString(applicationContext.getBeanDefinitionNames()));

}
}
1
등록 된 Bean[..., componentScanTest]

@ComponentScan 옵션
  1. @ComponentScan : 아무런 옵션도 주지 않는 경우로 해당 클래스가 위치한 패키지 내부를 basePackage로 설정합니다.
  2. @ComponentScan(basePackages = “패키지명”) : 위의 예제와 같은 경우로 직접 basePackage를 설정합니다.
  3. @ComponentScan(basePackageClasses = 클래스명.class) : 특정 클래스가 위치한 패키지를 basePackage로 설정할때 사용합니다.

스프링부트에서의 Bean 등록

스프링부트에서 제공하는 SpringBootApplication 어노테이션을 사용하면 위에서 작업했었던 component-scan, ApplicationContext 생성과 같은 소스코드를 작성할 필요가 없습니다. 해당 어노테이션이 자동으로 생성을 해 줍니다.


공부하면서 느낀점

XML로 Bean을 등록 하는 것보다는 IDE의 도움을 받을수 있는 자바소스로 설정하는게 좀더 편하다고 생각한다. 그리고 Bean을 직접 등록해서 사용하는 것보다는 component-scan을 이용하것이 좋을것 같다.

결론

직접 작성 한 클래스는 component-scan을 활용하고, 외부 라이브러리를 사용할시에는 @Bean을 직접 등록 해서 사용하자!

Comment and share

Spring-Test

스프링은 Junit을 이용하는 테스트 컨텍스트 프레임워크를 제공한다. 이를 이용하면 어노테이션을 이용하여 간편하게 컨텍스트를 사용할수 있다. 해당 방법이 없이 Bean을 사용하려면 직접 ApplicationContext를 생성하는 번거로운 작업을 진행하여야 하나 이로 인해 편하게 작업을 진행 할수 있다.

@ContextConfiguration

Comment and share

DataSourceUtils

in java, api

DataSource

DataSource는 ConnectionPool을 관리하기 위한 목적으로 사용되는 객체로 DataSource를 통해서 Connection을 얻어오고 반납하는 등의 작업을 구현합니다. ConnectionPool에는 여러개의 Connection 객체가 생성되어 운용되는데, 이를 직접 웹 어플리케이션에서 다루기 힘들기 때문에 DataSource라는 개념이 도입되었습니다.

DataSourceUtils

DataSourceUtils 클래스는 JNDI에서 연결을 얻고 필요한 경우 연결을 닫는 메소드를 제공하는 기능을 제공 합니다. 그리고 DataSourceTransactionManager로 쓰레드에 기반한 연결을 지원합니다.

DataSourceUtils에서 제공하는 메소드

getConnection(DataSource dataSource)

getConnection메소드는 제공 된 DataSource를 기반으로 하여 Connection을 생성해줍니다. Connection 생성은 트랜잭션 동기화 여부에 따라 다르게 작동합니다. 만약 트랜잭션 동기화가 활성화 되어 있다면 Connection을 생성하고 트랜잭션 저장소에 바인딩 합니다. 이후 트랜잭션 동기화 작업을 종료 할때까지 getConnection메소드를 호출하면 동일한 Connection을 반환하는 것을 확인할수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
public class DataSourceUtilsTest {
@Autowired
DataSource dataSource;

public void testGetConnection() {
TransactionSynchronizationManager.initSynchronization();

Connection conn1 = DataSourceUtils.getConnection(dataSource);
Connection conn2 = DataSourceUtils.getConnection(dataSource);

System.out.println("동일한 인스턴스 인가요? " + conn1.equals(conn2));
}
}

트랜잭션이 동기화되어 있지 않을 경우에는 dataSource.getConnection()과 동일하게 작동합니다. 그래서 항상 새로운 Connection을 반환합니다.

1
2
3
4
5
6
7
8
9
10
11
public class DataSourceUtilsTest {
@Autowired
DataSource dataSource;

public void testGetConnection() {
Connection conn1 = DataSourceUtils.getConnection(dataSource);
Connection conn2 = DataSourceUtils.getConnection(dataSource);

System.out.println("동일한 인스턴스 인가요? " + conn1.equals(conn2));
}
}

releaseConnection(Connection conn, DataSource dataSource)

releaseConnection메소드 또한 getConnection와 비슷하게 동작 합니다. 만약 트랜잭션 동기화가 활성화 되어 있다면 트랜잭션 저장소에서 Connection을 초기화 합니다. 이때 Connection의 연결은 종료하지 않습니다. 그리고 release 후 다시 getConnection으로 Connection을 받아왔을때 동일한 값이라는 것을 확인 할수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class DataSourceUtilsTest {
@Autowired
DataSource dataSource;

public void testGetConnection() {
TransactionSynchronizationManager.initSynchronization();

Connection conn = DataSourceUtils.getConnection(dataSource);

DataSourceUtils.releaseConnection(conn, dataSource);
System.out.println("Connection이 종료 되었니? " + conn.isClosed());

Connection conn2 = DataSourceUtils.getConnection(dataSource);

System.out.println("동일한 Connection 인가요? " + conn.equals(conn2));
}
}

위와 같이 releaseConnection 메소드를 호출 하더라도 Connection은 종료되지 않는다. 단지 트랜잭션에서만 제거되었을 뿐이다. 이 때문에 사용시 주의할 필요가 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class DataSourceUtilsTest {
@Autowired
DataSource dataSource;

public void testGetConnection() {
TransactionSynchronizationManager.initSynchronization();

Connection conn = DataSourceUtils.getConnection(dataSource);

System.out.println("트랜잭션 저장소에 저장 중인가? " + DataSourceUtils.isConnectionTransactional(conn, dataSource));

DataSourceUtils.releaseConnection(conn, dataSource);

TransactionSynchronizationManager.unbindResource(dataSource);
TransactionSynchronizationManager.clearSynchronization();

System.out.println("Connection이 종료 되었니? " + conn.isClosed());
System.out.println("트랜잭션 저장소에 저장 중인가? " + DataSourceUtils.isConnectionTransactional(conn, dataSource));
}
}

결론

DataSourceUtils를 사용하면 동기화된 트랜잭션의 Connection을 가져와서 사용하기에 좋다. 하지만 releaseConnection은 Connection을 종료해주는 기능이 아니므로 사용시에 주의할 필요가 있다.

트랜잭션 동기화 상태가 아닌 Connection이라면 releaseConnection메소드를 호출하면 close 해준다.

Comment and share

웹팩

in javascript, webpack

webpack.config.js

webpack.config.js 파일은 웹팩에 대한 기본적인 설정을 하는 파일입니다.

심플한 실제 파일 구성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
var path = require('path')	// output 속성에서 사용할 노드 path 라이브러리 저장
var webpack = require('webpack') // 웹팩 플러그인에서 사용할 웹팩 라이브러리를 저장

// 아래부터가 실질적인 웹팩의 설정 내용
module.exports = {
entry: './src/main.js', // 웹팩으로 빌드할 파일 지정(해당 파일의 앱의 첫 시작 파일이 되는 것)
output: { // output은 build 후에 생성 될 파일들에 대한 설정
path: path.resolve(__dirname, './dist'), // 빌드후에 결과 파일 저장 될 디렉토리
publicPath: '/dist/', // 이미지 파일 같이 주소의 앞에 prefix로 붙여주어 주소에 접근 하도록 해주는 것
filename : 'build.js' // 빌드하고 난 후 결과 파일
}
module: { // 지금까지는 loader를 사용하는 것 정도만 확인 했음
rules: [
{
test: /\.vue$/, // 로더가 적용 될 대상 파일 지정(정규식)
loader: 'vue-loader' // loader는 사용할 로더 지정
},
{
test: /\.js$/
loader: 'babel-loader',
exclude: /node_moules/ // 해당 디렉토리에서의 탐색은 제외하겠다
}
]
},
resolve: {
alias: { // 해당 하는 경로를 @로 대신 사용 가능하다, 여러개 편의성있게 등록 가능하다
'@': path.resolve(__dirname, 'src/')
},
extensions: ['*', '.js', '.vue', '.json'] // 해당하는 확장자들을 import하게 도와주는 역할
},
devtool: '#eval-source-map' // 웹팩으로 빌드된 파일로 웹앱 구동시에 개발자 도구에서 사용할 디버깅 방식 지정
}
```

## 웹팩 설정 구성에 사용 되는 용어 정리

### 1. entry

entry : 웹팩을 통해서 build를 할 대상 파일을 지정하는 속성
- 해당 파일에는 전체 애플리케이션 로직과 필요한 라이브러리를 로딩하는 로직이 들어가게 됩니다.

1
2

### 2. output

output : 웹팩으로 빌드한 결과물의 위치와 파일이름 등 세부옵션을 설정하는 속성

1
2

### 3. loader

loader : 웹팩으로 빌드할때 html, css 파일등을 자바스크립트로 변환하기 위해 필요한 설정을 정의

1
2

### 4. plugin

plugin : 웹팩으로 빌드 하고 나온 결과물에 대해 추가기능을 제공하는 속성
- 한마디로 필수옵션은 아니지만 빌드할때 혹은 결과물에 추가적인 기능을 적용하고 싶을 때 사용

1
2

### 5. resolve

resolve : 웹팩으로 빌드할때 해당 파일이 어떻게 해석되는지 정의하는 속성
- 예) 라이브러리 로딩시 버전은 어떤걸로 하고, 경로는 어디로 하고 등에 관한 것

Comment and share

데이터 흐름의 처리

1. vuex를 최대한 활용
1
흐름 : 부모 => actions => API => mutations => state => 자식에서 state 접근

이 방법은 vuex를 최대한 활용 하는 방법으로 데이터를 표현하는 곳에서 직접 state에 접근 하는 방법이다. 이때 데이터를 표현하는 곳에서는 actions를 호출하지 않는다.
내 생각에 actions에 대한 결합도가 높아지기 때문인듯하다(해당 컴포넌트의 범용성이 낮아진다).

2. props 활용
1
흐름 : 부모 => actions => API => mutations => state => 부모에서 state에 접근 후 props로 전달 => 자식

부모에서 API 호출 및 값을 가져와서 자식에게 props로 넘겨준다.

컴포넌트 태그처럼 명시적으로 표현하려면 이걸 쓰자.

Comment and share

vuex의 기본

in vue, vuex

vuex의 설치 및 시작

기본구성

설치

1
npm i vuex

vuex 구성

라우터와 마찬가지로 main.js에 직접 구성하는 것은 좋지 못하므로 다른 디렉토리를 구축해서 코드 구성은 해당 파일에서 작성하여 import만 해오자.

vuex의 정의

vuex란 간단히 말해 상태관리도구이다. 애플리케이션의 모든 컴포넌트에 대한 중앙 집중식 저장소 역할을 한다. 그래서 어느 컴포넌트에서나 쉽게 상태에 접근할수 있다.

simple vuex 코드

1
2
3
4
5
6
7
8
9
10
import Vue from 'vue';
import Vuex from 'vuex';

Vue.use(Vuex);

new Vuex.Store({
state: {
array: []
}
});

main.js

라우터와 마찬가지로 main.js에서 직접 Vuex를 생성하지 않고 따로 작성된 js에서 import 받아와서 사용한다.

1
2
3
4
5
6
import {store} from 'store/index.js';

new Vue({
render: h => h(App),
store
}).$mount('#app');

프로퍼티

1. state

state는 말그대로 상태를 저장하고 있다.

1
2
3
4
5
6
7
let vuex = {
state : {
array: [],
data: {},
str: ""
}
}
2. actions

api와의 통신 역할을 담당한다. api 호출 코드를 여기에서 작성 하면 된다. action에 정의 된 메소드라는 것을 표시하기 위해 대문자 스네이크 표기법을 강의에서는 사용했었다.

1
2
3
4
5
6
7
8
9
10
var actions = {
state: {},
actions: {
FETCH_DATA(context, param) {
fetchDataList()
.then()
.catch()
}
}
}

component에서 actions에 정의된 메소드 호출하기

1
2
this.$store.disaptch('메소드명');
this.$store.disaptch('메소드명', 값); // 값은 오직 하나만 전달 가능하므로 여러개를 전달하려면 객체를 통해 전달한다.

actions에서 api통신을 한 결과를 state에 전달하여야 하는데 이때 actions 내부에서 바로 state에 접근이 불가능하다. mutations라는 것을 통해서만 가능하다.
actions에 정의된 메소드의 파라미터로 context값이 넘어오는데 context의 commit 메소드를 호출하면 mutation에 전달가능하다.

1
2
3
4
5
6
7
8
9
10
11
12
var actions = {
state: {},
actions: {
FETCH_DATA(context, param) { // param에 dispatch를 실행할때 넘겼던 값을 받을수 있다.
fetchDataList()
.then(({ data }) => {
context.commit('mutation메소드명', '전달할 값')
})
.catch()
}
}
}
3. mutations

actions에서 backend(api)와이 실행 결과를 state에 저장할때 사용되는 중간 연결자이다. actions에서 context.commit으로 실행될 메소드를 정의한다.

1
2
3
4
5
6
7
8
9
10
11
var mutations = {
state: {
data: {}
},
actions: {},
mutations: {
SET_DATA(state, data) {
state.data = data;
}
}
}

첫번째 파라미터는 state가 넘어오고 두번째 파라미터는 commit 호출시에 넘겨준 파라미터가 넘어온다.

vue에서 store 접근

1. 가장 원시적인 방법

아래는 자바스크립트에서 사용방법

1
this.$store.state.프로퍼티

아래는 vue의 template에서 사용방법

1
<div>{{ this.$store.state.프로퍼티 }}</div>

위의 방법은 Vuex를 모듈방식으로 작성하기 시작하면 참조가 너무 길어진다.(a.b.c.d.e.f.g.value)

2. computed를 이용한 방법
1
2
3
4
5
6
7
var Vue = {
computed: {
state() {
return this.$store.state
}
}
}

단순하게 vue의 computed를 이용해서 공통된 부븐을 메소드에 저장하는 방법이다.

3. vuex의 mapState를 이용
1
2
3
4
5
6
7
8
9
import { mapState } from 'vuex';

var Vue = {
computed: {
...mapState({
value: state => state.value
})
}
}

vuex에서 제공하는 mapState를 활용하는 방법으로 파라미터로 state가 넘어오다보니 위와 마찬가지로 모듈이 많아지게 되면 state.a.b.c.d.value로 길어질수 있다.

4. vuex의 mapGetter를 이용(mapGetters의 배열을 이용하는 방법)
1
2
3
4
5
6
7
8
9
// vuex 파일

new Vuex.Store({
getters: {
value(state) {
return state.value;
}
}
})
1
2
3
4
5
6
7
8
// state 값 사용 할 파일
import { mapGetters } from 'vuex';

var Vue = {
computed: {
...mapGetters(['value'])
}
}

getters는 computed와 비슷한 역할을 한다. 컴포넌트에서는 mapGetter에서 배열을 넘겨준다(이때 배열의 문자열이 vuex의 getters에 정의 된 메소드 이름을 넘겨주면 해당값을 받아온다. getters에 등록 하는 번거로움이 있지만 사용할때는 변수명이 명료해서 보기 좋다.

5. vuex의 mapGetter를 이용(mapGetters의 객체를 이용하는 방법)

vuex 파일의 사용법은 위와 동일하다.

1
2
3
4
5
6
7
8
9
10
// state 값 사용 할 파일
import { mapGetters } from 'vuex';

var Vue = {
computed: {
...mapGetters({
myValue: 'value'
})
}
}

배열을 이용할때는 변수명을 마음대로 지정이 불가능하지만 객체를 이용하면 이름을 컴포넌트에서 마음대로 지정 할수 있다.

모듈화

하나의 파일에서 모든 데이터를 관리하면 알아보기 힘들기 때문에 모듈화 작업을 한다. mutations, actions, state, getters를 따로 파일을 만들어서 관리한다. 상황에 따라 분리 할수도 있고 길지 않다면 하나의 파일에서 관리할수 있고 더 세분화로 분리할수도 있다.

Comment and share

하이오더컴포넌트 기본사용 방법

정의

Mixin와 마찬가지로 컴포넌트의 로직을 재사용하기 위한 기술이다.

방법

1. 공통으로 사용할 부분을 js로 따로 만든다.
2. 함수를 하나 선언하고 return 해준다.
3. return에 들어가는 것 : render, 나머지 공통으로 사용되는 부분 작성
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
import Component from 'component.vue';

export default function hoc(componentName) {
return {
name: componentName, // 해당 이름으로 컴포넌트 생성됨
computed() {

},
data() {
return {

}
},
runder(h) {
return h(Component);
}
}
}

render 부분은 공통으로 사용되는 템플릿 부분을 사용하기 위한 것이다.

단점

HOC를 사용하게 되면 depth가 하나 추가된다. 이는 많이 사용하게 되면 컴포넌트의 깊이가 깊어져서 데이터 통신이 어려워진다.

1
2
일반구조 : 상위 - 하위
HOC구조 : 상위 - HOC - 하위

vue에서는 mixins와 scoped slotㅇ을 활용하고 함수형 프로그래밍이나 컴포넌트 재사용성을 극대화 하고 싶다면 HOC 활용하는것도 좋을거 같다.

Comment and share

Moon Star

author.bio


author.job