🙅🏿 ☺️ 🗯️ SPA baseado em navegador independente de estrutura 👨‍🌾 🙆🏿 👩🏾‍🏫

1. Mas ... por quê?

Existe um grande número de frameworks para o desenvolvimento de SPA (Single Page Application).
Há uma grande quantidade de documentação que ilustra como criar um aplicativo baseado em uma estrutura específica.
No entanto, qualquer documentação coloca a estrutura na vanguarda. Assim, transformando o framework de um detalhe de implementação em um fator determinante. Assim, uma parte significativa do código é escrita não para atender às necessidades do negócio, mas para atender às necessidades da estrutura.

Considerando o quanto o desenvolvimento de software é impulsionado pelo hype hoje em dia, você pode ter certeza de que em alguns anos haverá novos frameworks da moda para o desenvolvimento de front-end. No momento em que a estrutura com base na qual o aplicativo é construído sai de moda, você é forçado a manter a base de código legado ou iniciar o processo de transferência do aplicativo para uma nova estrutura.

Ambas as opções são prejudiciais para o negócio. Manter uma base de código desatualizada significa problemas com a contratação de novos desenvolvedores e motivação para os atuais. Transferir um aplicativo para uma nova estrutura custa tempo (e, portanto, dinheiro), mas não traz nenhum benefício comercial.

Este artigo é um exemplo de construção de um SPA usando princípios de design de arquitetura de alto nível. Ao fazer isso, bibliotecas e estruturas específicas são escolhidas para atender às responsabilidades definidas pela arquitetura desejada.

2. Objetivos e limitações arquitetônicas

Objetivos.

Um novo desenvolvedor pode entender o propósito de um aplicativo com uma rápida olhada na estrutura do código.
A separação de interesses é promovida e, portanto, a modularidade do código para que:
- Módulos são fáceis de testar
- (boundaries) . « »
. , .
. ( ) , .
.
. , .

. ( ) HTML+CSS JavaScript .

3.

. : (layered), (onion) (hexagonal). .

/ SPA . (domain) (application) . , — .

, .

( Ports and Adapters) . localStorage TodoMVC ( boundaries/local-storage).

4. . SPA ?

. :

1: ,

? 2 .

2: , 1

‘shared’ UI , , , .

( ) . ‘’ ‘parts’. ( 3).

3: ‘parts’

, ’goods catalogue’. ‘goods-catalogue/parts/goods-list/parts/good-details.js’ . — .

«parts» . 4.

4: ‘parts’

‘goods-catalogue/goods-list’ . goods-list.js () — , . , - (js, html, css) , , .

— .
- goods-list , .
- filters , .
( ) — «_». .
- _goods-list folder goods-catalogue .
- goods-list.js _goods-list .
- _good-details.js _goods-list .

5: «_»

! , . . pages components 5. HTML component. components , «» .

5. . JavaScript?

JavaScript. . ( 1-20), ...

, . . 4- . , 4 . . , 2015 , . , , .

JavaScript (babel) JavaScript, « » JavaScript. — , .

, — TypeScript :

- JavaScript, JavaScript
(typings) JavaScript . , npm . , TypeScript . -.

: asm.js, blazor elm

6.

, : HTML, CSS, JavaScript. , 4: , .

[6.1] HTML CSS .

HTML . , underscore.js, handlebars.js. , .

[6.2] TypeScript , (). .

UI . HTML HTML . . . . , .

[6.3] . .

[6.4] :

, .
. .
Domain Application. , Dependency Injection. .

— . . , , ----html-. . , .

, , . , . :

, .. .
.. .

, [6.5] — TypeScript . , .

, :

(Components) — HTML + CSS
(ViewModels) — , , ( ).
(ViewModel facades) — , .

- . .
().
— . / . «shared».
— . /.

? 6 . () . , .

[6.6] — .

7.

. — .

7.1.

- tsx ( jsx). tsx , React, Preact and Inferno. Tsx HTML, / HTML. tsx .. HTML, .

, , , JSX . React.

: React. react hooks - . API React , .

, . UI=F(S)

UI —
F —
S — ( — )

interface ITodoItemAttributes {
  name: string;
  status: TodoStatus;
  toggleStatus: () => void;
  removeTodo: () => void;
}

const TodoItemDisconnected = (props: ITodoItemAttributes) => {
  const className = props.status === TodoStatus.Completed ? 'completed' : '';
  return (
    <li className={className}>
      <div className="view">
        <input className="toggle" type="checkbox" onChange={props.toggleStatus} checked={props.status === TodoStatus.Completed} />
        <label>{props.name}</label>
        <button className="destroy" onClick={props.removeTodo} />
      </div>
    </li>
  )
}

todo TodoMVC .

— JSX. . , «».

[6.1] [6.2].

: react TodoMVC .

7.2. ()

, TypeScript -:

.
domain/application dependency injection.

, , .

(reactive UI). . WPF (C#) Model-View-ViewModel. JavaScript , (observable) (stores) flux. , :

, .

, , .
, .

mobx , . :

class TodosVM {
    @mobx.observable
    private todoList: ITodoItem[];

    // use "poor man DI", but in the real applications todoDao will be initialized by the call to IoC container 
    constructor(props: { status: TodoStatus }, private readonly todoDao: ITodoDAO = new TodoDAO()) {
        this.todoList = [];
    }
    public initialize() {
        this.todoList = this.todoDao.getList();
    }
    @mobx.action
    public removeTodo = (id: number) => {
        const targetItemIndex = this.todoList.findIndex(x => x.id === id);
        this.todoList.splice(targetItemIndex, 1);
        this.todoDao.delete(id);
    }
    public getTodoItems = (filter?: TodoStatus) => {
        return this.todoList.filter(x => !filter || x.status === filter) as ReadonlyArray<Readonly<ITodoItem>>;
    }
/// ... other methods such as creation and status toggling of todo items ...
}

mobx , .

mobx . mobx. .

{status: TodoStatus}

. [6.6]. . :

interface IVMConstructor<TProps, TVM extends IViewModel<TProps>> {
    new (props: TProps, ...dependencies: any[]) : TVM;
}
interface IViewModel<IProps = Record<string, unknown>> {
    initialize?: () => Promise<void> | void;
    cleanup?: () => void;
    onPropsChanged?: (props: IProps) => void;
}

. :

(-).

, ( statefull). .

7, . DOM(mounted) (unmounted). (higher order components).

 type TWithViewModel = <TAttributes, TViewModelProps, TViewModel>
  (
    moduleRootComponent: Component<TAttributes & TViewModelProps>,
    vmConstructor: IVMConstructor<TAttributes, TViewModel>,
  ) => Component<TAttributes>

moduleRootComponent, :

(mount) .
() (unmount).

TodoMVC . .. IoC , .

const TodoMVCDisconnected = (props: { status: TodoStatus }) => {
    return <section className="todoapp">
        <Header />
        <TodoList status={props.status} />
        <Footer selectedStatus={props.status} />
    </section>
};
const TodoMVC = withVM(TodoMVCDisconnected, TodosVM);

( , ), <TodoMVC status={statusReceivedFromRouteParameters} />

. , TodosVM

- TodoMVC

.

, , withVM.

TodoMVCDisconnected
TodoMVC ,
TodosVM . , , mobx .

: , withVM react context API. . , — connectFn .

7.3.

, / . 6 . .

«» , ( ) /, . (slicing function). , , ?

8: ( /slicing function)

( ):

type TViewModelFacade = <TViewModel, TOwnProps, TVMProps>(vm: TViewModel, ownProps?: TOwnProps) => TVMProps

connect   Redux. mapStateToProps

, mapDispatchToActions

  mergeProps

— , . TodoItemDisconnected

   TodosVM

.

const sliceTodosVMProps = (vm: TodosVM, ownProps: {id: string, name: string, status: TodoStatus; }) => {
    return {
        toggleStatus: () => vm.toggleStatus(ownProps.id),
        removeTodo: () => vm.removeTodo(ownProps.id),
    }
}

: , ‘OwnProps’ - react/redux.

— . withVM

. , , — , :

type connectFn = <TViewModel, TVMProps, TOwnProps = {}>
(
    ComponentToConnect: Component<TVMProps & TOwnProps>,
    mapVMToProps: TViewModelFacade<TViewModel, TOwnProps, TVMProps>,
) => Component<TOwnProps>
const TodoItem = connectFn(TodoItemDisconnected, sliceTodosVMProps);

todo : <TodoItem id={itemId} name={itemName} status={itemStatus} />

connectFn

:

TodoItemDisconnected

sliceTodosVMProps

— JSX.
, , , .

connectFn TodoMVC , .

8.

, , . TypeScript , , TSX — .

SPA . SPA « » « ».

, ?

- mobx, react mobx-react , :

mobx
- , . TodoMVC react-router react-router-dom.
, , JSX.

, .

, .

. React , .

P.S. SPA:

React/Redux: reducers, action creators middlewares. ( stateful). time-travel. . connect . Redux-dirven connected . , .
vue: TSX. , , . Vue.js ‘data’,’methods’, .. vue- .
angular: TSX. angular- . (two-way data binding). : , , .
react (hooks, useState/useContext): . , - . :
- .
- useEffect ‘deps’ .
- .
- .
, ( — useEffect) . , «», « (mental model)» « (best practices)». react. :
- ?
- , / , ? — . :
react-mobx . react-mobx . . .
Comparado com mobx-state-tree : Viewmodels são classes regulares e não requerem o uso de funções de bibliotecas de terceiros, nem precisam satisfazer a interface definida por frameworks de terceiros. A definição de tipo dentro da árvore mobx-state depende das funções específicas deste pacote. Usar mobx-state-tree em conjunto com TypeScript provoca duplicação de informações - campos de tipo são declarados como uma interface TypeScript separada, mas devem ser listados no objeto usado para definir o tipo.

O artigo original em inglês no blog do autor (eu)

SPA baseado em navegador independente de estrutura