Descomposición del proyecto para frontend

Hablemos de lo que ya sabes.

Este es mi primer artículo sobre Habré y no soy escritor. Pero mirando Frontend 2018: los resultados del año , las manos llegaron a lo sublime y comenzaron a escribir.

Cualquier tarea difícil consiste en tareas simples. La capacidad de descomponer correctamente es imprescindible .

Dirigiré la discusión sobre el ejemplo de la mayoría de los proyectos por experiencia personal.

Estoy seguro de que dirá: " Pero no lo tenemos y, en general, reaccionamos de manera rápida, lógica y legible, generar estilos usando js no es una especie de complemento, está de moda, pero los proveedores de servicios de fondo no son necesarios, porque nuestro proveedor de servicios de fondo Feofan hizo una excelente forma en php "pero aún así.

Designación
G1 Los genios que pueden, son excepciones, un caso magnífico especial.
M *. El pensamiento

Esto no se puede leer

¡Entonces comencemos!

M1 El código de doblaje es malo.

M2 Siempre debes pensar 100 pasos por delante.

Por ejemplo, al comienzo de un proyecto, tenemos en cuenta su estado después de 5 años.

Obviamente, al comenzar una red social, podemos decir de inmediato que, además de la versión web, habrá aplicaciones móviles, aplicaciones de escritorio. Desde aquí ...

M3 La parte del servidor debe escribirse solo una vez. (M1)

Y como tenemos una versión web, móvil, de escritorio, entonces ...

M4 El lado del servidor se ocupa de los datos.

El lado del servidor no debe decidir qué botón dibujar y de qué color debe ser.

Una plantilla de carta o un archivo html que [puede] se carga cuando una página se carga para que un motor de búsqueda la indexe también funciona con datos. Por desgracia, debe manipular html allí (debido a requisitos de indexación, por ejemplo), pero este es otro problema.

De hecho, uno podría transferir el conjunto inicial de archivos (html, js, css) y datos. Es decir y aquí la parte posterior no está involucrada en el diseño.

Aquí ocurrió el primer colapso del proyecto: la parte del servidor se rompió. No discutiré en qué idioma está escrito, cómo está organizada la arquitectura (recuerdo MVC). Este no es mi negocio para ...

M5 Todos deben hacer lo suyo.

Las pilas completas cubren algunos de los proyectos, y aquí puede argumentar con este punto, y discutiendo este punto, pero haciendo referencia a (M2) mi posición aquí está formada: es más barato tener dos profesionales en su campo que reescribir el proyecto en un año. Por supuesto, hay genios (G1) que se mantienen al día en todas partes, pero existen tales unidades, lo que significa que no puede tomarlas en los argumentos "Como debería ser".

También eliminaré de este pastel una rama de Designer, Usabilidad y compañía.

Entender correctamente, un proveedor de front-end normal puede implementar de forma independiente un hito, centrándose en un millón de análogos y su imaginación, pero estamos hablando de proyectos serios (M2), así que no te hagas ilusiones :) (G1)

Bueno, tenemos datos (api, todos los métodos necesarios, etc., etc.), tenemos diseños, y comencemos.

En vista de las realidades modernas, introduciría otra rama. Por desgracia, pero una gran proporción de los vendedores de front-end modernos no saben cómo trabajar con el diseño o no saben js. Realicé una gran cantidad de entrevistas y es extraño observarlo. Por lo tanto, los frentes se pueden dividir en "diseñadores de diseño" y "diseñadores que no son de diseño".

M6 El desarrollo debe estar en más de un archivo

Dime, obviamente? Si, obviamente!

M7 El frente está dividido en 2 partes: la que trabaja con los datos y la que los muestra.

Es posible que no tengamos esta o aquella parte. Por ejemplo: para ser solo display (página estática) o para ser solo datos (script en la consola, etc.).

Aquí sugiero abstraer y presentar: usted es una persona pizzería. Recibes llamadas, distribuyes el queso maravillosamente y se lo llevas al comprador. La lógica sugiere que no eres particularmente efectivo (M1). Pero si 2 personas más trabajaran contigo, ¡sería mucho mejor! Uno recibe llamadas (trabaja con datos), el segundo retoma (presentación), el tercero presenta el queso maravillosamente :) (estilización de la presentación)

Ya escuché "CEP" de 2012, "obviamente", pero volvamos a ...

M8 JS está trabajando con datos.

Llama al backend, acepta el pedido y no le importa cómo se pone el queso allí. Tal vez la pizza no existe en absoluto, ¿tal vez solo hace una encuesta de pizza del año?

M9 Representación HTML

Muestra pizza al cliente, y también acepta comentarios (dinero, comentarios) y los pasa al administrador (JS).

M10 CSS - estilo de presentación

Sangría entre las dos rebanadas de queso.

Tenga en cuenta que el administrador del teléfono no dice cómo apilar el queso, y la pizza no contiene a nadie hablando por teléfono. Cualquier intento de manipular estilos usando js, ​​o manipular js usando html es inicialmente un complemento, inicialmente es malo. Las clases y el manejo de eventos fueron inventados por una razón.

Puede poner una clase: pepperoni, salami, pero no es su competencia decidir cómo poner el queso pepperoni.

Puede anular: si fue expulsado, no pagó, dígaselo al administrador. Pero no empuje al administrador en la pizza. ¡Está solo y hay muchas pizzas! Si tiene tantas pizzas como operadores, entonces M1.

Y entonces, de los cuales js, css, html son responsables, lo descubrimos.

Ahora puede hacer ramas enteras de preguntas: cómo cocinar pizza, cómo entregarla más rápido y más conveniente, y cómo hablar con los clientes por teléfono.

Quiero de alguna manera definir la palabra de moda " Componente ". De hecho, incluso un botón normal ya es un "Componente", pero lo redefiniré con ejemplos obvios. Un botón es un botón y un componente:

1. Vista previa de la publicación
2. Comentario
3. Vista previa del archivo
4. Votar en el habr
5. El bloque "vacantes"
6. Texto HTML de la publicación, reseñas, seminario web
etc.

M11. Un componente debería verse igual en todas partes.

Donde sea que publique una vista previa de la publicación, en qué página la abra, debería verse igual. La regla de los tres colores. Todo debe ser reconocible para el usuario.

Modificaciones: cambios forzados, si es necesario. Hecho con CSS.

¿O es otro componente?

(Por ejemplo, la vista previa de la publicación en la columna derecha puede diferir de la vista previa de la publicación en la parte inferior de la página).

M12 El componente consta de [html], [js], [css].

Cada una de las partes es opcional.

M13 Independientemente del número de instancias del mismo componente, sus estilos deben registrarse solo una vez

Por ejemplo, la vista previa de la publicación a la derecha, la vista previa de la publicación a continuación, la vista previa de la publicación en la notificación y los estilos se registran solo una vez.

M14. Solo la base debe estar registrada en el componente js

Por ejemplo, los controladores de eventos al hacer clic en los botones, datos necesarios para mostrar. Todo lo demás debe ser procesado.

M15 Un componente puede consistir en componentes

Por ejemplo, una lista de publicaciones.

M16. Estilos sacados en un archivo separado

Estos archivos están en caché, además, no habrá tentación de escribirlos en línea, lo que significa duplicarlos.

M17. Los estilos de componentes deben vincularse a través de clases primarias y solo

La página de cualquier sitio es como una gran cantidad de cajas de diferentes tamaños, que son como muñecas de anidación incrustadas entre sí.

Una caja es un componente.

Tienes una caja con cajas y artículos. Nunca necesita pensar en cómo describir el interior de una caja anidada. Describe solo esto.

Aquí inventaron un montón de bicicletas, pero caballeros, no habrá problemas con los nombres, tan pronto como determinen el conjunto de componentes por sí mismos. Si abres VKontakte y cuentas el número de componentes allí, bueno, cuentas 30 piezas. (No cuentes con facebook, solo hay dolor).

¿No se te ocurren 30 nombres de clase? Y con razón, no hay nada que se le ocurra:

M18. Otras personas leerán tu código.

Entonces el nombre natural es el mejor nombre

Por ejemplo

1. lista de publicaciones
2. lista de comentarios
3. lista de noticias
4. vista previa
5. comentario-vista previa
6. vista previa de noticias
7. post-detalle
8. comentario-detalle
9. noticias-detalle

Increíblemente difícil, ¿eh? Y lo principal es incomprensible y difícil de mantener

Y sobre el "leer a otras personas" también darse de baja:

M19 ¡Html, js, css deben almacenarse por separado!

Si necesita combinarlos, busque una solución diferente a escribirlos en un archivo. ¡Reaccionar es lo más desagradable en términos de legibilidad que he visto!

La página de "Cajas" se dividió, se discutió cómo almacenar archivos. Que mas

M20. Casi no hay casos especiales

Y si sucede, mañana sus gerentes irán a trabajar y le dirán que "es necesario modificar la implementación a pedido del cliente". Resuelva tareas de la forma más amplia posible.

Por ejemplo, en nuestro trabajo, independientemente del proyecto, separamos inmediatamente algunas tareas: calendarios, formularios de entrada, ventanas emergentes, menús de diferentes rellenos, visualización de archivos y otros widgets que interactúan con el usuario. Por así decirlo, "funciones de caracteres"

M21 La escritura de estilo requiere descomposición

El mundo no solo nos ha dado el maravilloso MENOS, SASS.

Su proyecto tiene un conjunto fijo de fuentes, colores, sombras, casi todos los proyectos serios tienen esquemas de color, por lo que al escribir estilos, todo esto se parametriza. Y aquí lo siguiente es importante

M22 Si desea cambiar el color de fuente (etc.), solo debe realizar ediciones en un lugar

En conclusión, me gustaría mencionar un problema importante.

M23 La formulación correcta del problema conduce a la solución correcta.

Quizás entonces no habría css-in-js, facebook y algo que no debería llamarse.

¡Que tengan un buen día todos!