<p>디바 2.0</p>

ts에 대한 기본 지원은 어떻습니까?

모델링을 해제할 때 사용하지 않는 상태 데이터를 파괴하기 위해 감속기를 전달하는 것을 지원하는 것을 고려하십니까? https://github.com/dvajs/dva/issues/769

로드호그로 이름을 바꾼 dva-cli는 어떻습니까? 개념이 혼동되지 않도록 하십시오.

개인적으로, 나는 ts에 대한 기본 지원에 동의하지 않습니다. 프레임워크는 다른 관련 없는 기술 스택에서 바인딩을 해제하고 순수하게 유지해야 하며 오히려 덜 수행해야 합니다. 예를 들어 모델 마운트 해제의 상태 문제는 다음과 같이 수행할 수도 있습니다. 기존 api, react-router react-router-dva와 같은 독립된 컴포넌트로 분리할 계획이며, rn용 react-navigation-dva도 작성할 수 있습니다.

dva.use(reselect) 와 같은 플러그인 형태로도 지원할 수 있는 최적화 방식도 있으며 익스프레스 미들웨어 메커니즘과 마찬가지로 정적 플러그인만 내장하고 나머지는 별도로 지원합니다. , 심지어 사가도 가능합니다.

@nihgwu antd 와 마찬가지로 ts로 작성되어 사용자를 제한하지 않는다는 뜻으로, 항상 수동으로 동기화하고 유형 파일을 게시할 필요가 없다는 장점이 있습니다.

플러그인 솔루션에 동의합니다. 다음을 수행할 수 있습니까?

view - dva-core - [插件]

그 중 현재 dva에 해당하는 부분은 다음과 같습니다.

• dva 코어
• dva-saga
• 라우터

마지막 두 가지는 플러그인입니다.

뷰와 데이터 간의 관계를 표현하는 데 중점을 둔 라이브러리로 dva를 포지셔닝할 수 있습니까? 뷰는 어떤 프레임워크이며 데이터 소스는 어떤 방식으로 대체 가능합니까? 그런 다음 1.0으로 원활하게 업그레이드하려면 dva를 dva-core와 saga의 기본 조합으로 정의해야 합니까?

기본 캡슐화가 인스턴스 유형의 디스패치 유형을 지원하는 데 편리한지 모르겠습니다.

dispatch({
  type: model => model.product.loadAll,
})

문자열 외우기도 귀찮고 네임스페이스 작성을 잊어버리는 경우가 많고, 드롭다운 프롬프트가 있으면 재구성하는 것도 편리합니다~

상태의 모든 데이터에 대해 기본적으로 감속기 세트를 제공할 수 있는지 모르겠습니다.
대부분의 시나리오에서는 필드에 값을 할당할 수 있는 리듀서를 수동으로 작성해야 하므로 기본적으로 기성품의 단일 필드 세트 방법을 제공할 수 있다면 꽤 좋을 것입니다.

리듀서를 트리로 구현할 수 있나요?지금처럼 ns split은 로직을 평평하게 하기 위해 강제로 적용됩니다.모델은 리듀서의 루트에 해당하고, 아래에 매달려 있는 리듀서가 너무 많습니다.

@xufei 사가가 핵심이 되어야 한다고 생각하는데 사가가 없는 현재의

@xufei 죄송합니다 저도 ts로 쓰는거 참고하시면

@sorrycc Separating saga 나도 예를 들어 dva의 핵심이 redux + redux-saga인 것은 맞지만 구현의 관점에서 보면 콜백 후크를 통해 플러그인으로 분리할 수 있다.

Immutable.js를 지원할 수 있습니까?

Immutable.js 지원, Immutable.js는 성능 최적화에서 중요한 역할을 합니다.

로드호그 패키징은 성능을 너무 많이 소모합니다. 최적화할 수 있는지 확인하십시오. 가능하면 최대한 최적화하십시오. 이제 서버가 프로젝트를 빌드하기 전에 다른 컨테이너를 중지해야 합니다. 그렇지 않으면 서버가 중단됩니다.

Immutable.js는 더 이상 사용되지 않습니다. lodash와 Spread 작업을 결합하면 불변 효과를 얻을 수도 있습니다. 그리고 lodash는 기본적으로 내장되어 있습니다.

사실 dva 1.x의 개발 경험은 이미 매우 좋은데 Immutable.js, split saga, native support ts 지원 여부와 비슷하고, 불필요하다고 느끼고, 모두 개발자의 자기애에 속하고, 별로 실제 개발 효율성과 경험에 영향을 미칩니다.

개인적으로 dva 2.x에서 고려해야 할 4가지 사항이 있습니다.

1. 서비스 계층의 최적화 여부, 모델로 추출할 수 있는지, 통합된 방식으로 패키징하는지 여부는 기본적으로 request 신경 쓰지 않고 기본적으로 네트워크 예외 처리를 제공하며 이제 기본적으로 필요합니다. request.js 직접 쓰려면;

2. 뷰 레이어의 이펙트 콜백 문제로 비즈니스 로직을 완전히 모델 데이터로 분리하여 이펙트로 처리하는 것은 비현실적(너무 번거로움)이므로 이 부분에서 좀 더 세련된 솔루션이 필요합니다.

3. 그것은 dva의 주변 커뮤니티를 구성하는 것입니다. 현재 스캐폴딩의 유형은 예제가 풍부하지만 더 많은 구성이 필요합니다. 목표는 각도 또는 반응 커뮤니티 자체의 리소스 수준에 도달하는 것 같습니다.

4. 빌드 도구, 성능, 기능 등의 향상(현재 모의)은 여전히 ​​약간 번거롭습니다.

저에게 가장 우려되는 것은 router 의 분리입니다. dva 에는 redux + redux-saga 만 포함하면 된다고 생각합니다. redux 커뮤니티는 가능한 한 적게 하는 것을 옹호하므로 1.x 패키징 react-router 및 fetch 는 물론 위에서 언급한 Immutable 도 불필요하게 느껴집니다. 이것은 개발자의 취향에 속한다 유지자로서 편향되어서는 안 된다 개발자의 취향에 따라 플러그인 형태로 지원될 수 있다 서비스 계층의 문제도 있다 필요에 따라 , plugin 직접 작성할 수 있습니다. dva-core 포함되어서는 안 됩니다.

@nihgwu 라우터를 추출하는 목적은 무엇입니까?

@nikogu는 너무 많은 일을 했고 초보자는

라우터를 제거하는 목적은 무엇입니까?

@nikogu

현재 dva의 적용 범위는 다소 좁고, 자연스럽게 view를 포함하는 react 커뮤니티와 강하게 연결되어 있고 react-router와도 강하게 연결되어 있습니다. 그러나 그것을 사용한 후에 나는 무선 다중 페이지 응용 프로그램과 같이 라우터가 필요하지 않은 곳, react-native와 같이 react-router를 적용할 수 없는 곳, node와 같이 react가 필요하지 않은 곳을 발견했습니다. , 전자 및 애플릿.

나는 dva가 더 많은 것을 할 수 있다고 생각합니다.

@nikogu는 라우터가 다르기 때문에 라우터를 멀리합니다.예를 들어 RN에서는 react-navigation을 사용할 수 있고 react-navigation은 웹도 지원하므로 플러그인에서 완벽하게 지원하여 더 나은 사용자 정의를 달성할 수 있습니다.

dva는 노드의 기존 API를 사용하여 웹 서버의 기본 기능을 제공하는 express와 같은 완전한 웹 개발 프레임워크 세트를 제공하기 보다는 redux 및 saga 코드와 로직을 새로운 형태로 구성하는 것으로 알고 있습니다. 본문, 쿠키 및 미들웨어를 통해 사용자 정의할 수 있는 템플릿 엔진을 선택합니까?

완전한 솔루션이 마음에 들면 dva-ant = dva-core + dva-plugins 구현하여 사용할 수 있습니다.

dva의 조합은 redux와 saga의 조합이어야 합니다. 왜냐하면 이 두 가지는 데이터 상태 흐름의 핵심이고 나머지는 데이터를 기반으로 구축된 주변 장치로만 간주될 수 있고 플러그인이나 다른 방법으로 지원될 수 있기 때문입니다. 우리는 Express와 Django를 비교할 수 있습니다. 덜 하는 것과 더 많이 하는 것의 전형적인 차이점입니다. 어떤 사람들은 크고 완전한 것을 좋아하지만 js 커뮤니티는 작지만 아름다운 것을 존중합니다.

redux를 직접 사용하는 경우 dva를 사용하는 가장 큰 이유는 dva가 redux의 코드 구조와 로직을 단순화하고 생산 효율성을 높일 수 있기 때문이며, 이것이 redux 기반 dva의 핵심이기도 합니다.

맹목적으로 더 많이 하면 dva의 응용 시나리오는 점점 더 좁아질 것입니다.예를 들어 react-router는 RN에서 사용할 수 없습니다(v4는 이미 지원하지만 매우 기본적임), RN도 fetch와 함께 제공되며 다른 강력한 바인딩이 있습니다. . 라이브러리는 또한 업그레이드 종속성 문제를 일으킬 것입니다. 여전히 반응 라우터입니다. V4는 RN을 지원하지만 dva는 여전히 V2입니다. dva가 반응 라우터를 업그레이드할 때까지 기다려야 사용할 수 있습니다. 플러그인인 경우 에서 독립적으로 업그레이드하면 이러한 문제가 발생하지 않습니다. NS

위의 dva-core가 의미하는 바는 작은 코어를 dva-core로 취급하고 여기에 라우터 등을 가져온 다음 중간 및 백오피스를 위한 회사의 내부 통합 버전과 같은 몇 가지 기본 통합 체계를 개발하는 것입니다. , H5의 경우 소규모 프로그램, 서버 측 렌더링 등

2:00:
1. 실제 개발에서 비즈니스 로직이 모델에 구현되어 있는데 파일이 너무 큰데 상대방과 서비스의 관계는? 서비스 또는 요청 내장 가능
2. react-router를 시스템 자체 플러그인으로 변경하거나 종속성을 해제하는 것이 목적입니다.

2.0은 언제 시작되나요?

Pluggable ssr 솔루션은 라우터의 관리를 추상화합니다. 서버 측이 첫 번째 라우팅 요청을 인수하고 공유 dva()를 사용하여 상태 트리를 초기화할 수 있습니다. dva가 계속 업그레이드됨에 따라 서버 렌더링이 약하다고 느낍니다. 새로운 기능의 적용.

TypeScript 및 RN.더 나은 지원을 바랍니다

다른 것을 생각해 보세요. 기본 namespace 제공하세요.

dva를 사용하는 과정에서 항상 reducer 접두사가 필요하지 않고 dva의 현재 구현이 namespace 제공해야 하는 경우가 있으므로 namespace 는 default (또는 global , * )이고 model 아래의 reducers 는 접두사 없음

개인적으로 몇 가지 사항을 생각해 보십시오.

• redux-saga 에 의존하지 않으므로 일부 기능(예: async/await 지원)을 쉽게 추가할 수 있습니다.
• 여러 개의 작은 모듈로 분할(예: 단일 상점, 단일 라우터)
• 중첩 모델 지원

우리는 최근 모델 vuex 에 따라 redux 쓴 기준점 : https://github.com/d-band/yax

서버측에서 렌더링이 가능하고 프론트엔드와 백엔드를 함께 쓸 수 있는 것을 추천합니다!

경로 디렉토리의 이름을 설정할 수 있습니까? 예를 들어 컨테이너 사용
사실, 나는 기능별로 카탈로그를 나누고 모델, 서비스 및 컨테이너를 함께 넣고 싶습니다. 그렇지 않으면 여러 카탈로그로 이동하면 마음의 흐름이 파괴됩니다. 숭고한 탭에서 열린 user.js가 무엇인지 알기 위해 이미 user.jsx, user.model.js, user.service.js와 같이 이름을 지정했습니다. user/model.js, service.js, container.js를 합칩니다.

@zheeeng 과 같은 디렉토리 구성이 이제 지원되며 dva는 디렉토리 구성에 제한이 없습니다.

@xufei
@sorrycc

모델링을 해제할 때 사용하지 않는 상태 데이터를 파괴하기 위해 감속기를 전달하는 것을 지원하는 것을 고려하십니까?

수동 제어는 너무 번거롭습니다. GC 세트를 직접 구현하는 것이 좋습니다.

pathToRegexp를 업그레이드하십시오. 구문 분석 및 컴파일 방법을 직접 사용할 수 없습니다.

합의는 구성보다 낫고 다른 프로젝트나 기술 스택과의 결합을 줄입니다.

효과 사업이 너무 무겁고 모델 확장의 아이디어가 상당히 좋습니다.

@nihgwu는 개인적으로 "

@sorrycc dva 2.0에 최신 릴리스 계획이 있습니까?

dva-cli가 TypeScript 상용구를 생성하도록 선택할 수 있기를 강력히 바랍니다.

dva-core는 이미 WeChat 애플릿에서 사용할 수 있습니다.

@yautah가 시도 했습니까? 당신이 그것을 시도한 후 계획을 공유할 수 있습니다.

dva-core는 redux 데이터 스트림 재캡슐화만 제공하면 된다고 생각합니다.

스타일러스를 지원하기 위해 dva-cli를 지원하기를 바랍니다.

ssr을 지원하지 않습니다.

HRM 구성 방법, API 작성이 상대적으로 적음