Este documento presenta los principios de diseño para componentes web. Describe brevemente qué son los componentes web, por qué son útiles y cómo permiten encapsular lógica, comportamiento y presentación de forma adaptable y reutilizable. También explica que los principios de diseño ayudan a crear componentes que sean robustos, duraderos y capaces de integrarse bien con otros componentes.

1. Javier
Vélez
Reyes
@javiervelezreye
Javier.velez.reyes@gmail.com
Principios
de
Diseño
en
Componentes
Web
Programación
Orientada
a
Componentes
Web
Marzo
2015

2. @javiervelezreye
2
Autores
Principios
de
Diseño
en
Componentes
Web
Licenciado
en
informá2ca
por
la
UPM
desde
el
año
2001
y
doctor
en
informá2ca
por
la
UNED
desde
el
año
2009,
Javier
es
inves2gador
y
su
línea
de
trabajo
actual
se
centra
en
la
innovación
y
desarrollo
de
tecnologías
de
Componentes
Web.
Además
realiza
ac2vidades
de
evangelización
y
divulgación
en
diversas
comunidades
IT,
es
Polymer
Polytechnic
Speaker
y
co-­‐organizador
del
grupo
Polymer
Spain
que
conforma
una
comunidad
de
interés
de
ámbito
nacional
en
relación
al
framework
Polymer
y
a
las
tecnologías
de
Componentes
Web.
I.
¿Quién
Soy?
II.
¿A
Qué
Me
Dedico?
javier.velez.reyes@gmail.com
@javiervelezreye
linkedin.com/in/javiervelezreyes
gplus.to/javiervelezreyes
jvelez77
javiervelezreyes
youtube.com/user/javiervelezreyes
Polymer
Polytechnic
Speaker
Co-­‐organizador
de
Polymer
Spain
Evangelización
Web
Desarrollador
JS
Full
stack
Arquitectura
Web
Formación
&
Consultoría
IT
e-­‐learning

3. Javier
Vélez
Reyes
@javiervelezreye
Javier.velez.reyes@gmail.com
1
Introducción
§ Qué
son
los
Componente
Web
§ Por
Qué
los
Componentes
Web
§ Por
Qué
Principios
de
Diseño
para
Componentes
Web
§ El
Paradigma
de
Componentes
Web
Introducción
Principios
de
Diseño
en
Componentes
Web

4. @javiervelezreye
4
Introducción
Principios
de
Diseño
en
Componentes
Web
Qué
son
los
Componentes
Web
La
tecnología
de
Componentes
Web
proporciona
un
mecanismo
para
construir
nuevas
e2quetas
de
autor
personalizadas
que
incluyen
una
semán2ca,
un
comportamiento
funcional
y
una
lógica
de
presentación
propia.
E2quetas
de
Autor
Componentes
Web

5. @javiervelezreye
5
Introducción
Principios
de
Diseño
en
Componentes
Web
Por
Qué
Componentes
Web
Un
Componente
Web
encapsula
cierta
lógica
funcional
y
presentacional
elaborada
que
se
ac2va
desde
el
navegador
como
una
simple
e2queta
estándar
de
HTML.
Encapsulación
de
la
Lógica
Comportamiento
AdaptaRvo
Los
componentes
se
desarrollan
para
hacerse
responsables
de
la
ges2ón
del
espacio
en
el
área
de
presentación,
de
las
necesidades
de
accesibilidad
y
las
preocupaciones
generales
de
usabilidad.
RWD
&
AWD
Accesibilidad
Usabilidad

6. @javiervelezreye
6
Introducción
Principios
de
Diseño
en
Componentes
Web
Por
Qué
Componentes
Web
Los
componentes
Web
también
fomentan
un
proceso
de
diseño
Web
que
2ende
a
la
homogenización
lo
que
desde
un
punto
de
vista
corpora2vo
resulta
ventajoso.
Homogenización
del
diseño
GesRón
de
la
Evolución
Centralizada
La
lógica
de
presentación
de
los
componentes
Web
se
puede
adaptar
evolu2vamente
bajo
demanda
de
las
necesidades
empresariales
sin
impactar
en
el
correcto
funcionamiento
de
los
aplica2vos
y
si2os
web
que
hacen
uso
de
los
mismos.
Restaurante Diversia
9.7 (51)
Casa de Campo
Puerta del Sol
Plaza Mayor
Línea
evoluDva
t1
t2
t3
Los
usuarios
perciben
los
cambios
instantáneamente
v1
v2
v3

7. @javiervelezreye
7
Introducción
Principios
de
Diseño
en
Componentes
Web
Por
Qué
Componentes
Web
La
tecnología
de
componentes
Web
ofrece
la
posibilidad
de
exponer
los
servicios
de
una
organización
en
forma
de
un
conjunto
de
e2quetas
visuales
que
conectan
con
capacidades
de
negocio.
Orientación
a
la
Vista
Construcción
ComposiRva
Como
cualquier
otra
e2queta
estándar
los
componentes
Web
pueden
conectarse
de
forma
composi2va
a
través
de
las
relaciones
de
anidamiento
y
propagación
de
eventos
que
soporta
la
Web.
C
R
U
D
Servicios
REST
HTTP
Usuario
Programador
Usuario
Final
Los
componentes
Web
están
orientación
a
la
vista

8. @javiervelezreye
8
Introducción
Principios
de
Diseño
en
Componentes
Web
Por
Qué
Principios
de
Diseño
Para
Componentes
Web
WebComponents.org
is
where
pioneers
and
community-­‐
members
of
the
Web
Components
ecosystem
(like
Polymer,
X-­‐tags,
and
other
interested
par2es)
document
web
components
best
prac2ces
so
that
others
can
follow
the
same
path
instead
of
needlessly
striking
out
on
their
own.
-­‐
Zeno
Rocha
¿Cómo
se
que
mi
componente
es
suficientemente
reuRlizable?
¿Cómo
se
cuándo
debo
aplicar
encapsulación
o
simple
agregación?
¿Cómo
se
que
mi
componente
va
a
perdurar
en
el
Rempo?
¿Cómo
se
que
mi
componente
está
preparado
para
uRlizarse
en
muchos
contextos?
¿Cómo
se
si
mi
componente
se
integrará
bien
con
los
demás?
?
?
?
?

9. @javiervelezreye
9
Introducción
Principios
de
Diseño
en
Componentes
Web
Por
Qué
Principios
de
Diseño
Para
Componentes
Web
Podemos
exponer
gráficamente
todos
los
obje2vos
primarios
y
secundarios
vinculados
a
la
tecnología
de
componentes
Web.
Los
principios
de
diseño
nos
ayudarán
a
alcanzar
dichos
obje2vos.
Encapsulación
AdaptaRvidad
Homogeneidad
EvoluRvidad
Visualidad
ComposiRvidad
Sencillez
DeclaraDvidad
Agilidad
Reusabilidad
Diversidad
Accesibilidad
Usabilidad
Estandarización
Reducción
de
código
Alineamiento
a
dominio
Orientación
a
negocio
Mantenibilidad
Perdurabilidad
Estabilidad
Robustez
Dialectalidad
Usabilidad
Orientación
a
Cliente
MulDcanalidad
Interoperabilidad
Integración
Coordinación
Contextualización

10. @javiervelezreye
10
Introducción
Principios
de
Diseño
en
Componentes
Web
Ejes
Dimensionales
El
Paradigma
de
Componentes
Web
En
torno
al
concepto
de
componente
Web
se
pueden
describir
tres
ejes
dimensionales.
Los
obje2vos
determinan
los
propósitos
perseguidos,
los
mecanismos
caracterizan
las
capacidades
na2vas
de
plataforma
y
los
principios
de
diseño
ofrecen
directrices
generales
de
actuación.
Principios
Mecanismos
Vis
Evo
Hom
Ada
ObjeRvos
Los
objeDvos
describen
las
caracte-­‐
rísDcas
diferenciales
de
los
componentes
Web
y
jusDfican
su
uso
en
los
procesos
de
desarrollo
de
soluciones
Web
¿Qué?
Los
principios
de
diseño
ofrecen
líneas
maestras
que
dirigen
los
procesos
de
desarrollo
del
so^ware
orientado
a
componentes
Web
¿Cómo?
Los
mecanismos
conforman
las
herramientas
de
la
plataforma
para
arDcular
el
desarrollo
del
so^ware
orientado
a
componentes
Web
¿Con
qué?
Dom
Cmp
Enc
Std
Tmp
Evt
Her
DBin
cic

11. @javiervelezreye
11
Introducción
Principios
de
Diseño
en
Componentes
Web
Planos
de
AcRvidad
El
Paradigma
de
Componentes
Web
La
intersección
de
las
dimensiones
por
pares
configura
tres
planos
de
ac2vidad.
En
el
plano
arquitectónico
se
definen
los
es2los
arquitectónicos
o
modelos
de
programación
soportados
por
el
paradigma.
En
el
plano
de
diseño
se
establecen
los
patrones
fundamentales.
Y
en
el
plano
tecnológico
se
describen
las
técnicas
u2lizadas.
Principios
Mecanismos
Los
esDlos
arquitectónicos
propor-­‐
cionan
restricciones
estructurales
que
determinan
y
condicionan
los
procesos
de
desarrollo
EsRlos
Arquitectónicos
El
diseño
establece
formas
canónicas
de
aplicabilidad
probada
para
dar
respuesta
a
problemas
recurrentes
Patrones
Las
técnicas
indican
cómo
aplicar
los
mecanismos
de
la
plataforma
en
el
proceso
de
desarrollo
para
alcanzar
los
objeDvos
Técnicas
Patrones
Diseñadores
Arquitectos
Plano
Tecnológico
Programadores
ObjeRvos
Vis
Evo
Hom
Ada
Dom
Cmp
Enc
Std
Tmp
Evt
Her
DBin
cic

12. @javiervelezreye
12
Introducción
Principios
de
Diseño
en
Componentes
Web
AcRvidades
El
Paradigma
de
Componentes
Web
Sobre
este
espacio
dimensional
pueden
ubicarse
las
ac2vidades
que
conforman
los
procesos
de
desarrollo
de
sobware
orientado
a
componentes
Web.
En
lo
que
resta
de
este
trabajo
nos
centraremos
en
describir
los
principios
de
diseño
fundamentales.
Otros
elementos
serán
cubiertos
en
próximos
trabajos.
Principios
Mecanismos
Patrones
Diseñadores
Arquitectos
Plano
Tecnológico
Programadores
ObjeRvos
Vis
Evo
Hom
Ada
Dom
Cmp
Enc
Std
Tmp
Evt
Her
DBin
cic
AcRvidades
Foco
de
atención

13. Javier
Vélez
Reyes
@javiervelezreye
Javier.velez.reyes@gmail.com
2
Principios
de
Diseño
§ Introducción
§ Principios
de
Diseño
en
el
Stream
OOP
§ Principios
de
Diseño
en
el
Stream
COP
§ Principios
de
Diseño
en
el
Stream
SOC
Introducción
Principios
de
Diseño
en
Componentes
Web

14. @javiervelezreye
14
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Introducción
Dom
Aco
Abs
Reu
Est
Com
Std
Adp
Evo
Ctx
A
lo
largo
de
este
capítulo
revisaremos
los
principios
fundamentales
que
guían
el
proceso
de
diseño
y
construcción
de
componentes
Web.
Orientación
a
Objetos
Orientación
a
Componentes
Computación
Distribuida
Este
material
entronca
con
los
streams
fundamentales
de
desarrollo
vigentes
en
la
actualidad.
Su
contenido
ha
sido
cuidadosamente
adaptado
para
encajarlos
en
las
necesidades
y
peculiaridades
arquitectónicas
que
demanda
la
tecnología
de
componentes
Web.
Enc

15. @javiervelezreye
15
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Introducción
La
descripción
detallada
de
cada
uno
de
los
principios
que
se
enumeran
en
este
trabajo
se
realizará
en
torno
a
un
esquema
de
caracterís2cas
que
recogen
de
manera
sumarial
las
preocupaciones
esenciales
que
dichos
principios
abordan.
A
con2nuación
presentamos
cuáles
son
tales
caracterís2cas.
Nombre
Describe
el
nombre
del
principio
Refiere
a
los
principales
implicados
en
el
desarrollo
del
principio
Actores
Enuncia
las
directrices
generales
que
se
enmarcan
bajo
el
principio
Descripción

16. @javiervelezreye
16
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Introducción
La
descripción
detallada
de
cada
uno
de
los
principios
que
se
enumeran
en
este
trabajo
se
realizará
en
torno
a
un
esquema
de
caracterís2cas
que
recogen
de
manera
sumarial
las
preocupaciones
esenciales
que
dichos
principios
abordan.
A
con2nuación
presentamos
cuáles
son
tales
caracterís2cas.
Facetas
Cada
principio
se
analiza
desde
una
colección
de
facetas
complementarias
Los
ejemplos
ilustran
la
aplicación
de
cada
faceta
en
la
prác2ca
y
en
su
mayoría
son
extraídos
del
código
y
documentación
de
Polymer
Ejemplo
Las
facetas
se
acompañan
de
explicaciones
que
ayudan
a
entender
su
relevancia
Explicación

17. @javiervelezreye
17
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Introducción
La
descripción
detallada
de
cada
uno
de
los
principios
que
se
enumeran
en
este
trabajo
se
realizará
en
torno
a
un
esquema
de
caracterís2cas
que
recogen
de
manera
sumarial
las
preocupaciones
esenciales
que
dichos
principios
abordan.
A
con2nuación
presentamos
cuáles
son
tales
caracterís2cas.
ObjeRvos
Se
describe
la
colección
de
obje2vos
que
se
persiguen
con
la
aplicación
del
principio
Se
describen
las
fases
de
aplicación
del
principio
dentro
de
los
proyectos
de
construcción
o
uso
de
componentes
Fases
Se
ilustran
las
regiones
en
el
marco
de
la
arquitectura
donde
impacta
la
aplicación
del
principio
Región
Se
ofrece
el
fundamento
que
jus2fica
y
mo2va
el
principio
MoRvación

18. @javiervelezreye
18
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Introducción
La
descripción
detallada
de
cada
uno
de
los
principios
que
se
enumeran
en
este
trabajo
se
realizará
en
torno
a
un
esquema
de
caracterís2cas
que
recogen
de
manera
sumarial
las
preocupaciones
esenciales
que
dichos
principios
abordan.
A
con2nuación
presentamos
cuáles
son
tales
caracterís2cas.
Tensiones
Se
analiza
la
repercusión
de
la
aplicación
del
principio
en
relación
con
los
demás
principios
Se
argumenta
la
razón
del
impacto
en
cada
principio
para
aquellos
casos
de
mayor
correlación
Argumentos

19. @javiervelezreye
19
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Introducción
La
descripción
detallada
de
cada
uno
de
los
principios
que
se
enumeran
en
este
trabajo
se
realizará
en
torno
a
un
esquema
de
caracterís2cas
que
recogen
de
manera
sumarial
las
preocupaciones
esenciales
que
dichos
principios
abordan.
A
con2nuación
presentamos
cuáles
son
tales
caracterís2cas.
Ejemplo
Desde
una
perspec2va
visual
se
presentan
ejemplos
que
aplican
claramente
el
principio
Se
ofrecen
explicaciones
en
relación
a
por
qué
el
componente
de
ejemplo
cumple
el
principio
Comentarios

20. @javiervelezreye
20
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Diseño
Centrado
en
el
Dominio
Analista
de
Dominio
Arquitecto
de
Componentes
Nombre
Actores
Comienza
siempre
realizando
una
adecuada
división
de
responsabilidades
en
el
ámbito
de
tu
dominio
y
garan2zando
la
ausencia
de
huecos
y
solapamientos
entre
componentes.

21. @javiervelezreye
21
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Por
norma
general,
cuando
trabajas
construyes
familias
de
componentes
que
incluyes
en
una
librería
de
e2quetas
personalizadas.
Un
componente
aislado
puede
ser
puntualmente
ú2l
pero
frecuentemente
forma
parte
de
una
colección
de
otros
componentes.
Nunca
Defines
Componentes
Aislados
<google-map latitude="37.77493"
longitude="-122.41942"
fitToMarkers>
<google-map-marker
latitude="37.779"
longitude="-122.3892"
draggable="true"
title="Go Giants!">
</google-map-marker>
</google-map>
Los
componentes
aislados
no
suelen
ser
frecuentes
en
el
paradigma
de
componentes
El
componente
google-­‐map-­‐marker
opera
siempre
en
el
ámbito
light
DOM
de
un
componente
google-­‐map
Es
frecuente
construir
componen-­‐
tes
por
familias
que
operan
de
manera
coopera2va
En
este
ejemplo
se
ve
como
los
componentes
trabajan
frecuentemente
de
manera
conjunta.

22. @javiervelezreye
22
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Siempre
que
construyes
componentes
Web
estás
elaborando
un
dominio
cuyos
componentes
se
aplicarán
en
mul2tud
de
proyectos.
Esto
significa
que
tus
clientes
de
librería
no
son
clientes
finales
sino
desarrolla-­‐
dores
de
proyecto.
Estás
Contribuyendo
A
Dominio
<google-analytics-dashboard>
<google-analytics-view-selector>
</google-analytics-view-selector>
<google-analytics-chart
metrics="ga:sessions"
dimensions="ga:date">
</google-analytics-chart>
</google-analytics-dashboard>
Los
desarrolladores
u2lizan
discrecional-­‐
mente
estos
componentes
en
sus
proyectos
En
este
ejemplo
se
ve
como
Google
ha
adaptado
su
API
de
análisis
creando
una
librería
de
componentes
Web.
librería
Proyecto
B
Proyecto
A
usa
usa
Dominio
Usa
componentes
para
desarrollar
tus
proyectos.
No
desarrolles
componentes
para
usar
en
tus
proyectos.

23. @javiervelezreye
23
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Antes
de
empezar
la
construcción
de
una
librería
de
componentes
determina
el
ámbito
preciso
de
responsabilidades
que
quieres
cubrir
con
ella.
Lo
prioritario
es
tener
claro
qué
capaci-­‐
dades
quieres
cubrir
con
tu
librería
y
qué
otras
dejarás
conscientemente
fuera.
Define
El
Alcance
Un
buen
ejemplo
de
alcance
de
librería
lo
encontramos
en
la
orientación
a
componentes
que
Google
ha
hecho
de
sus
APIs.
Dominio
librería
Existen
ámbitos
dentro
del
dominio
que
estratégicamente
se
decide
dejar
no
cubiertos
El
alcance
de
librería
se
puede
definir
en
términos
de
la
proporción
de
dominio
que
ésta
abarca
google-­‐analy2cs-­‐base
google-­‐analy2cs-­‐chart
google-­‐analy2cs-­‐dashboard
google-­‐analy2cs-­‐date-­‐selector
google-­‐analy2cs-­‐query
google-­‐analy2cs-­‐view-­‐selector
google-­‐map
google-­‐map-­‐direc2ons
google-­‐map-­‐marker
google-­‐map-­‐search
Cada
una
de
estas
dos
librerías
se
centra
en
dar
cobertura
a
las
necesidades
concretas
dentro
de
un
dominio
especifico

24. @javiervelezreye
24
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Asegúrate
de
que
la
construcción
de
tu
librería
de
componentes
Web
sólo
aborda
competencias
propias
del
dominio
al
que
pertenece.
Incluir
componentes
en
tu
librería
fuera
del
alcance
de
su
dominio
provoca
colisiones
potenciales
con
otras
librerías.
Centra
El
Dominio
La
librería
core-­‐*
de
Polymer
es
un
claro
contraejemplo
de
diseño
centrado
en
el
dominio.
Dominio
A
librería
Es
importante
asegurarte
que
tu
librería
pertenece
enteramente
a
un
único
dominio
Dominio
B
core-­‐a11y-­‐keys
core-­‐ajax
core-­‐xhr
core-­‐localstotage
core-­‐media-­‐query
core-­‐meta
core-­‐shared-­‐lib
core-­‐signals
core-­‐style
core-­‐animated-­‐pages
core-­‐drag-­‐drop
core-­‐drawer-­‐panel
core-­‐header-­‐panel
core-­‐overlay
core-­‐scaffold
core-­‐spliher
core-­‐menu
core-­‐pages
core-­‐scroll-­‐header-­‐panel
core-­‐scroll-­‐threshold
core-­‐selec2on
core-­‐selector
Helpers
Control
Layout
Dentro
de
la
librería
se
encuentran
categorías
funcionales
muy
dispares
En
este
ejemplo
la
librería
invade
parte
del
dominio
A

25. @javiervelezreye
25
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
La
aplicación
de
las
dos
facetas
anteriores
puede
reformularse
en
términos
de
la
cohesión.
Se
dice
que
existe
cohesión
alta
en
una
librería
si
sus
componentes
están
altamente
relacionados.
Existen
dis2ntos
2pos
de
cohesión
que
pueden
ser
establecidos
sobre
una
librería
de
componentes.
Por
orden
de
impacto
de
nega2vo
a
posi2vo
éstos
son
los
siguientes.
Fomenta
La
Cohesión
De
Librería
Coincidental
Temporal
Informacional
Funcional
Dos
componentes
se
incluyen
en
la
misma
librería
por
criterios
arbitrarios
Lógica
Procedimiental
Secuencial
Dos
componentes
se
incluyen
en
la
misma
librería
por
pertenecer
a
una
categoría
lógica
común
Dos
componentes
se
incluyen
en
la
misma
librería
porque
siempre
se
usan
de
acuerdo
a
un
determinado
orden
Dos
componentes
se
incluyen
en
la
misma
librería
porque
siempre
se
conectan
composi2vamente
en
los
diferentes
contextos
de
uso
Dos
componentes
se
incluyen
en
la
misma
librería
porque
se
usan
siempre
a
la
vez
Dos
componentes
se
incluyen
en
la
misma
librería
porque
operan
sobre
el
mismo
2po
de
datos
Dos
componentes
contribuyen
unifor-­‐
memente
a
un
conjunto
de
responsa-­‐
bilidades
relacionadas
en
el
dominio
-­‐
+

26. @javiervelezreye
26
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Para
definir
el
alcance
de
tu
librería
de
componentes
distribuye
las
competencias
que
desees
cubrir
entre
espacios
de
responsabilidad
disjuntos.
La
división
en
espacios
de
responsabilidad
organiza
el
alcance
ya
que
explicita
y
aclara
la
descomposición
que
se
hace
del
dominio
en
el
marco
de
la
librería.
Define
Espacios
De
Responsabilidad
Nuevamente
la
librería
de
componentes
de
Google
que
encapsula
las
capacidades
de
Google
Maps
es
un
ejemplo
de
buena
segmentación
de
responsabilidades.
librería
El
alcance
es
una
caracterís2ca
invariante
que
se
establece
en
el
2empo
de
diseño
de
la
librería.
La
cobertura
puntual
de
requisitos
que
den
los
componentes
no
guarda
relación
con
esta
caracterís2ca
r1
r7
r4
r3
r5r6
r2
r8
r9
Un
espacio
de
responsa-­‐
bilidad
es
un
clasificador
de
competencias
dentro
del
alcance
de
la
bibliote-­‐
ca
google-­‐map
google-­‐map-­‐direc2ons
google-­‐map-­‐marker
google-­‐map-­‐search
Cada
una
de
las
cuatro
e2quetas
cons2tuyentes
se
dirigen
a
cubrir
una
competencia
ortogonal
en
el
marco
del
sistema
de
mapas
de
Google

27. @javiervelezreye
27
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Durante
el
proceso
de
análisis,
diseño
y
construcción
de
componentes
asegúrate
de
que
no
produces
solapamientos
funcionales
entre
los
mismos.
Cada
componente
será
ahora
responsable
de
implementar
las
competencias
definidas
en
el
marco
de
uno
y
sólo
uno
de
los
espacios
de
responsabilidad.
Evita
Solapamientos
Funcionales
Como
contraejemplo
de
segmentación
de
responsabilidades
podemos
volver
a
traer
la
librería
core-­‐*.
Incluso
dentro
de
los
componentes
de
control
las
competencias
entre
e2quetas
están
solapadas.
librería
La
segmentación
completa
y
disjunta
en
espacios
de
responsabilidad
ayuda
a
garan2zar
ausencias
de
solapamien-­‐
tos
funcionales
entre
componentes
Lo
que
en
cualquier
caso
hay
que
garan2zar
es
que
ningún
componente
se
posiciona
entre
dos
espacios
de
responsabili-­‐
dad
Pese
a
que
a2enden
a
contextos
arquitectó-­‐
nicos
de
uso
diferentes,
las
e2quetas
core-­‐
selec2on
y
core-­‐selector
presentan
solapa-­‐
mientos
funcionales
en
relación
al
control
de
la
interacción
core-­‐menu
core-­‐pages
core-­‐scroll-­‐header-­‐panel
core-­‐scroll-­‐threshold
core-­‐selec2on
core-­‐selector
Control

28. @javiervelezreye
28
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Las
dependencias
en
el
dominio
son
una
consecuencia
del
proceso
de
división
de
responsabilidades.
Una
vez
establecidos
los
componentes
analiza
las
dependencias
emergentes.
Dis2ntos
criterios
de
división
en
espacios
de
responsabilidad
conducen
potencial-­‐
mente
a
dis2ntos
conjuntos
de
depen-­‐
dencias
entre
los
componentes.
Descubre
Las
Relaciones
De
Composición
Emergentes
En
este
ejemplo
la
relación
de
dependen-­‐
cia
entre
componentes
es
una
clara
consecuencia
de
los
criterios
de
división
de
responsabilidades
establecidos
librería
Es
importante
descubrir
las
dependencias
de
dominio
y
dis2nguirlas
claramente
de
aquellas
mo2vadas
por
una
decisión
de
diseño
o
implementación.
El
principio
de
acoplamiento
se
ocupará
posteriormente
de
éstas
úl2mas
r1
r7
r4
r3
r5r6
r2
r8
r9
Una
vez
iden2ficado
cada
componente
estudia
las
relaciones
que
guarda
con
los
componentes
de
su
vecindad
<google-map latitude="37.77493"
longitude="-122.41942"
fitToMarkers>
<google-map-marker
latitude="37.779"
longitude="-122.3892"
draggable="true"
title="Go Giants!">
</google-map-marker>
</google-map>
El
componente
google-­‐map-­‐marker
se
debe
evaluar
en
el
contexto
DOM
de
un
componente
google-­‐map

29. @javiervelezreye
29
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
§ Organizar
el
proceso
de
desarrollo
§ Garan2zar
una
buena
cobertura
§ Evitar
el
versionado
§ Mantener
acotado
el
alcance
§ Facilitar
la
evolución
§ Planificar
el
trabajo
en
equipo
§ Promover
dialectos
de
dominio
Análisis
&
Diseño
de
Dominio
ObjeRvos
Fases
Fronteras
de
Dominio
Relaciones
de
Dependencia
Región
Librería
Dominio
Frontera
de
Dominio
Relaciones
de
Dependencia
El
principio
de
diseño
centrado
en
el
dominio
persigue
orientar
el
proceso
de
desarrollo
de
una
librería
para
asegurar
su
aplicabilidad
máxima.
MoRvación

30. @javiervelezreye
30
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Tensiones
Una
adecuada
división
de
responsabilidades
permite
obtener
componentes
con
mayores
oportunidades
de
reuDlización
Un
cuidadoso
análisis
de
dominio
evita
escenarios
de
adaptación
pero
facilita
su
aplicabilidad
discrecional
Una
adecuada
división
del
dominio
en
parcelas
bien
definidas
de
responsabilidad
permite
definir
las
líneas
evoluDvas
de
cada
componente
Aco
Abs
Dom
Reu
Est
Com
Adp
Evo
Enc
Std
Ctx
Un
análisis
centrado
en
el
alcance
del
dominio
favorece
encontrar
las
abstracciones
adecuadas
Un
análisis
del
dominio
descuidado
puede
generar
acoplamientos
no
previstos
La
organización
del
dominio
promueve
que
los
componentes
se
integren
fluidamente
en
el
contexto
de
uso

31. @javiervelezreye
31
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Diseño
Centrado
en
el
Dominio
Ejemplo
E-­‐commerce
App
hhp://goo.gl/3MHSkg
La
tecnología
de
componentes
Web
permite
definir
familias
de
elementos
de
interfaz
para
dar
respuesta
a
las
necesidades
de
negocio
específicas
vinculadas
a
un
dominio

32. @javiervelezreye
32
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
Acoplamiento
Débil
Arquitecto
&
Desarrollador
de
Componentes
Nombre
Actores
Cuando
construyas
un
componente
asegúrate
de
minimizar
el
número
de
dependencias
existentes
y
de
mantener
un
diseño
agnós2co
de
las
caracterís2cas
de
las
mismas.

33. @javiervelezreye
33
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
Durante
las
fases
de
diseño
y
desarrollo
conviene
analizar
la
prescindibilidad
de
las
dependencias
entre
componentes.
En
la
medida
de
lo
posible
reduce
al
máximo
su
número.
Las
dependencias
que
un
componente
establece
con
su
vecindad
limitan
su
autonomía
y
los
escenarios
en
los
que
éste
puede
operar.
Minimiza
Las
Dependencias
Un
componente
sin
dependencias
o
sólo
con
dependencias
opcionales
es
ideal.
Uno
de
tantos
ejemplos
es
el
google-­‐
signin.
Cada
dependencia
supone
un
riesgo
de
propagación
de
errores
entre
componentes
y
una
traba
para
la
evolución
Frecuentemente
el
exceso
de
dependencias
está
mo2vado
por
una
mala
estrategia
de
diseño
que
puede
ser
solventada
con
el
uso
de
patrones
que
fomenten
el
desacoplamiento
<google-signin
clientid="..."
scopes="profile"
role="button"
tabindex="0">
</google-signin>
Google-­‐signin
es
un
componente
para
poder
auten2ficarse
en
un
tercero
a
través
de
las
credenciales
de
Google.
Su
carácter
autónomo
sirve
de
ejemplo
en
esta
faceta

34. @javiervelezreye
34
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
Procura
que
dentro
de
tu
arquitectura
se
mantenga
un
conocimiento
explícito
de
todas
las
dependencias
obligatorias
que
cada
componente
2ene
con
la
vecindad.
Las
dependencias
obligatorias
entre
componentes
son
aquellas
necesarias
para
garan2zar
su
correcto
funciona-­‐
miento.
Haz
Explícitas
Las
Dependencias
Obligatorias
Por
ejemplo
considere
un
componente
asistente
que
requiere
obligatoriamente
hacer
uso
de
una
ventana
modal
donde
mostrar
la
ayuda.
La
explicitación
arquitectónica
se
hace
patente
al
observar
el
código
interno
del
componente.
La
mejor
forma
de
conseguirlo
es
mediante
el
uso
del
modelo
de
paso
de
mensajes
(llamadas
a
métodos).
A
necesitará
una
referencia
explicita
a
B
dentro
de
su
código
La
explicitación
arquitectónica
de
las
dependencias
obligatorias
exige
tenerlas
en
cuenta
en
cualquier
escenario
de
uso
m
A
B
<core-overlay id="A">
<h2>Help</h2>
...
<button toggle-btn>OK</button>
</core-overlay>
<wc-help-assistant
window="A">
</wc-help-assistant>
open
El
asistente
de
ayuda
usa
la
ventana
modal
y
la
abre
o
cierra
explícitamente
por
invocación
de
sus
métodos.
La
referencia
explícita
a
A
en
el
atributo
window
ayuda
a
destacar
la
existencia
de
una
dependencia
obligatoria
close
El
core-­‐overlay
expone
métodos
para
abrir
y
cerrar
explícita-­‐
mente
la
ventana
modal

35. @javiervelezreye
35
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
Procura
que
dentro
de
tu
arquitectura
se
mantengan
ocultas
todas
las
dependencias
opcionales
que
cada
componente
2ene
con
la
vecindad.
Las
dependencias
opcionales
sirven
para
comunicar
información
a
los
componen-­‐
tes
de
la
vecindad
que
no
son
necesaria-­‐
mente
requeridos
para
el
correcto
funcio-­‐
namiento
del
componente.
Haz
Implícitas
Las
Dependencias
Opcionales
La
comunicación
desacoplada
puede
realizarse
en
Polymer
mediante
arquitec-­‐
turas
de
eventos
o
memoria
compar2da
por
data
binding.
<div on-core-select="{{A.fn}}">
<core-pages selected="{{s}}">
<div>Page 1</div>
<div>Page 2</div>
</core-pages>
</div>
event
A
El
modelo
de
propagación
de
eventos
es
una
de
las
soluciones
para
ocultar
dependencias
opcionales
ya
que
los
receptores
no
se
hacen
explícitos
dentro
del
código
de
A
{{x}}
Los
modelos
de
data
binding
basados
en
memoria
compar2da
son
otra
forma
de
ocultación
de
dependencias
ya
que
cada
componente
no
es
consciente
de
quién
recibe
la
información
compar2da
fn
A
B
event
{{s}} C
Cada
vez
que
en
core-­‐pages
se
selecciona
una
página
se
dispara
un
evento
core-­‐select
que
escucha
A.
Asimismo
los
cambios
son
propagados
por
data
binding
en
la
variable
s
lo
que
permite
informar
a
B
y
C
s
s

36. @javiervelezreye
36
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
En
términos
generales
procura
que
en
tus
diseños
de
componentes
la
comunicación
entre
los
mismos
se
realice
de
manera
no
directa.
Los
esquema
de
indirección
siempre
fomentan
el
desacoplamiento
ya
que
permiten
segmentar
la
comunicación.
Busca
La
Indirección
Un
buen
ejemplo
de
comunicación
indirecta
por
paso
de
mensajes
se
da
entre
el
componente
core-­‐icon
y
el
core-­‐
iconset.
{{x}}
Escriben
Leen
C
As
Bs
event
Los
escritores
As
se
comunican
con
los
lectores
Bs
a
través
de
C
A
se
comunica
con
los
escuchadores
Bs
a
través
de
eventos
Los
componentes
se
comunican
a
través
del
uso
de
la
variable
compar2da
x
Bs
A
core-­‐iconset
<core-iconset
id="my-icons"
src="my-icons.png"
icons="site place ...">
</core-iconset>
<core-icon icon="my-icons:location">
</core-icon>
core-­‐icon
core-­‐iconset
es
una
factoría
de
iconos
que
deposita
iconos
en
una
base
de
datos
local
core-­‐meta
Las
familias
de
iconos
son
recogidas
desde
la
base
de
datos
por
core-­‐icon

37. @javiervelezreye
37
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
En
el
marco
de
una
comunicación,
el
diseño
de
un
componente
no
debería
verse
influenciado
por
quién
o
quienes
son
los
demás
componentes
implicados
en
la
misma.
Al
diseñar
un
componente
no
debería
importar
el
2po,
comportamiento,
propósito
o
iden2dad
del
resto
de
compo-­‐
nentes
implicados
en
una
comunicación.
No
Importa
Quién
El
componente
core-­‐selec2on
es
un
buen
ejemplo
de
diseño
que
man2ene
el
desacoplamiento
de
cliente.
El
diseño
del
contrato
del
componente
D
no
se
debe
ver
influenciado
por
dis2ntos
2pos
de
componentes
cliente
que
lo
puedan
u2lizar
A
B
C
D
click
<div on-click='{{fn}}'>
</div>
A
B
core-­‐selec2on
expone
un
contrato
basado
en
el
método
select.
Es
responsabilidad
de
los
clientes
A
y
B
adaptarse
a
su
forma
de
operar
El
componente
A
comunica
sus
cambios
por
emisión
de
eventos
core-select
<core-selection>
</core-selection>select
El
componente
B
comunica
sus
cambios
por
invocación
de
métodos

38. @javiervelezreye
38
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
En
el
marco
de
una
comunicación,
el
diseño
de
un
componente
no
debería
verse
influenciado
por
dónde
se
encuentran
los
demás
componentes
implicados
en
la
misma.
Al
diseñar
un
componente
no
debería
importar
la
posición
rela2va
en
el
DOM
donde
residen
el
resto
de
componentes
implicados
en
una
comunicación.
No
Importa
Dónde
En
este
caso
el
componente
paper-­‐tabs
nos
sirve
de
contraejemplo
para
ilustrar
el
desacoplamiento
a
contexto.
Componentes
receptores
e
interesados
Componentes
no
receptores
e
interesados
event
El
componente
decide
por
diseño
no2ficar
acontecimientos
rele-­‐
vantes
por
medio
de
la
propaga-­‐
ción
de
eventos
Los
componentes
situados
en
la
cadena
de
ascendencia
de
A
son
capaces
de
recibir
sus
eventos
Otros
componentes
mal
posicio-­‐
nados
no
pueden
acceder
a
los
eventos
de
A
pero
eso
es
algo
que
no
debería
competer
al
componente
A
A
<div on-core-select="{{A.fn}}">
<paper-tabs>
<paper-tab>1<paper-tab>
<paper-tab>2<paper-tab>
</paper-tabs>
<div>...</div>
</div>
Los
componentes
escuchadores
deben
registrarse
necesariamente
en
algún
nivel
dentro
de
la
cadena
de
ascendencia
de
paper-­‐tabs
Otros
componentes
mal
posicionados
no
podrán
establecer
una
comunicación
con
paper-­‐tabs
core-select
fn
A

39. @javiervelezreye
39
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
En
el
marco
de
una
comunicación,
el
diseño
de
un
componente
no
debería
verse
influenciado
por
cuántos
son
los
demás
componentes
implicados
en
la
misma.
Al
diseñar
un
componente
no
debería
importar
la
can2dad
de
componentes
que
par2cipan
potencialmente
en
una
comunicación.
No
Importa
Cuántos
El
componente
paper-­‐radio-­‐group
es
un
ejemplo
de
cómo
una
no2ficación
de
selección
se
puede
desacoplar
de
la
can2dad
de
escuchadores.
event
El
componente
B
decide
por
diseño
comunicar
el
cambio
de
estado
a
través
de
la
llamada
a
un
método
A
y
así
se
independiza
del
número
de
escuchadores
Dado
que
hay
N
interesados
en
el
cambio
de
estado
de
B,
A
funciona
de
intermediario
para
no2ficar
dichos
cambios
Los
interesados
en
os
cambios
de
B
reciben
las
no2ficaciones
de
cambio
a
través
del
interme-­‐
diario
A
A
B
<div on-core-select="{{gn}}">
<div on-core-select="{{fn}}">
<paper-radio-group>
<paper-radio-button/>
...
<paper-radio-button/>
</paper-radio-group>
</div>
</div>
selectNext
core-select
gn
fn
El
componente
A
cambia
el
estado
de
selección
invocando
a
selectNext()
sin
ser
consciente
de
cuántos
serán
sus
receptores
A

40. @javiervelezreye
40
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
En
el
marco
de
una
comunicación,
el
diseño
de
un
componente
no
debería
verse
influenciado
por
la
can2dad
de
información
adicional
que
se
comparte
dentro
de
la
misma.
Al
diseñar
un
componente
no
deberían
importar
los
cambios
en
la
can2dad
de
información
que
se
comparta
a
lo
largo
del
2empo.
No
Importa
Cuánto
El
siguiente
ejemplo
ilustra
bien
la
transferencia
de
un
volumen
de
datos
potencialmente
variante.
<google-map map="{{map}}"
latitude="37.779"
longitude="-122.3892">
</google-map>
<google-map-directions map="{{map}}"
startAddress="San Francisco"
endAddress="Mountain View">
</google-map-directions>
OUT
IN
{{map}}
A
lo
largo
del
2empo
el
componente
google-­‐
map
podría
ir
incluyendo
nueva
información
no
dirigida
a
google-­‐map-­‐direc2ons
dentro
del
objeto
map
Los
cambios
adi2vos
sobre
el
objeto
map
no
deberían
impactar
en
el
funcionamiento
de
google-­‐map-­‐direc2ons
A
B
C
D
{{x}}
{{x}}
{{x}}
x = {
foo: 1,
bar: 2,
baz: 3
}
A
comunica
una
estructura
de
datos
x
a
B,
C,
y
D
Cada
componente
B,
C,
D
hace
sólo
uso
de
parte
de
los
datos
en
x
sin
importar
el
resto
x.foo
x.bar
x.baz
x.bar
x.baz

41. @javiervelezreye
41
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
En
el
marco
de
una
comunicación,
el
diseño
de
un
componente
no
debería
verse
influenciado
por
cuándo
se
produce
la
información
compar2da
dentro
de
la
misma.
Al
diseñar
un
componente
no
debería
importar
con
qué
desfase
llega
a
los
des2natarios
la
información
compar2da
en
una
comunicación.
No
Importa
Cuándo
Muchos
componentes
de
Polymen
en
las
librerías
core-­‐*
y
paper-­‐*
u2lizan
la
e2queta
core-­‐meta
para
ofrecer
desaco-­‐
plamiento
temporal.
e
set
{{x}}
get
Ninguno
de
los
medios
de
comunicación,
mensajes,
data
binding
&
eventos
presenta
desacoplamiento
temporal
ya
que
requiere
que
los
componentes
des2natarios
estén
ac2vos
en
el
momento
de
la
comunicación
Es
buena
idea
introducir
intermediarios
que
garan2cen
desacoplamiento
temporal
<core-meta id="A">
<property name="x" value="1">
</property>
</core-meta>
Ps
C
var m = document.createElement('core-meta');
var data = m.byId('A');
console.log(data);
x : 1
A
P
C
P
u2liza
core-­‐meta
para
escribir
un
dato
en
el
espacio
A
Una
nueva
instancia
de
core-­‐meta
permite
a
C
posteriormente
acceder
a
los
datos
en
A

42. @javiervelezreye
42
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
En
el
marco
de
una
comunicación,
el
diseño
de
un
componente
no
debería
verse
influenciado
por
la
frecuencia
con
la
que
otros
componentes
interactúan
dentro
de
la
misma.
Al
diseñar
un
componente
no
debería
importar
con
qué
frecuencia
llegan
solici-­‐
tudes
al
mismo
desde
los
demás
par2-­‐
cipantes
en
una
comunicación.
No
Importa
Cada
Cuánto
Existen
muchas
librerías
como
underscore.js
que
permiten
implementar
componentes
C
que
ar2culen
polí2cas
de
throhling.
eeeeee
e e e
El
componente
A
emite
eventos
con
una
frecuencia
excesiva
para
el
des2natario
B
Gracias
a
C,
la
frecuencia
con
que
B
recibe
eventos
está
más
amor2guada
B
A
C
El
componente
C
recibe
eventos
de
A
y
los
retransmite
a
B
ges2onando
el
throhling
<div on-mousemove="{{C.hn}}">
</div>
_.throttle(function(e){
this.fire(e);
}.bind(this), 3000);
hn
e
e
A
B
C

43. @javiervelezreye
43
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
§ Aumentar
la
mantenibilidad
§ Simplificar
el
uso
§ Simplificar
el
desarrollo
§ Facilitar
la
sus2tución
§ Fomentar
la
autonomía
§ Mejorar
la
evolu2vidad
Diseño
de
Dominio
Desarrollo
de
Componentes
ObjeRvos
Fases
Contrato
de
Componentes
Relaciones
de
Dependencia
Región
El
principio
de
acoplamiento
débil
persigue
obtener
componentes
idealmente
autónomos
que
sean
fácilmente
reu2lizables
en
dis2ntos
contextos
de
uso.
MoRvación
Librería
Dominio
Contrato
de
Componentes
Relaciones
de
Dependencia

44. @javiervelezreye
44
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
Cuantas
menos
dependencias
presenta
un
componente
mayor
libertad
de
reuDlización
ofrece
El
bajo
acoplamiento
permite
arDcular
técnicas
de
adaptación
en
los
componentes
Dom
Abs
Est
Com
Adp
Evo
Enc
Std
Ctx
ArDcular
mecanismos
de
desacoplamiento
conduce
a
generar
confusión
en
el
dominio
Reu
Aco
El
desacoplamiento
permite
una
integración
grácil
en
el
contexto
Los
componentes
con
bajo
acoplamiento
son
más
fácilmente
encapsulables
El
desacoplamiento
ofrece
más
grados
de
libertad
en
la
evolución
del
componente
Tensiones

45. @javiervelezreye
45
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Acoplamiento
Débil
Collec2on
hhp://goo.gl/6nLcbk
Este
componente
no
presenta
dependencias
con
ningún
otro
elemento
Cada
avatar
es
un
componente
que
es
responsable
de
su
propio
rendering
con
lo
que
el
volumen
de
información
intercambiada
es
nulo
Cuando
pinchas
en
un
item
de
la
colección
se
le
comunica
al
padre
por
eventos
Ejemplo

46. @javiervelezreye
46
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Abstracción
Analista
de
Dominio
Arquitecto
&
Desarrollador
de
Componentes
Nombre
Actores
Asegúrate
siempre
de
que
tus
componentes
operan
al
nivel
más
elevado
de
abstracción
posible
dentro
de
los
contextos
de
colaboración
en
que
par2cipen.

47. @javiervelezreye
47
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Durante
la
definición
del
contrato
de
un
componente
asegúrate
de
que
no
expones
detalles
internos
de
implementación
y
de
que
revelas
la
mínima
can2dad
de
información
posible
sobre
él.
Incluye
la
parte
pública
en
el
proto2po.
Usa
los
mecanismos
de
declaración
de
atributos
de
Polymer
para
definir
el
estado.
Encapsula
mediante
clausuras
las
partes
privadas.
Abstrae
Los
Detalles
core-­‐ajax
es
un
buen
ejemplo
de
componente
que
permite
realizar
una
prolija
operación
abstrayendo
de
los
detalles
de
implementación.
Atributos
Propiedades
Capacidades
Controladores
Manejadores
Variables
implementación
Helpers
Adaptadores
…
Estado
Funciones
Pública
Privada
<core-ajax
auto
url="..."
params="..."
handleAs="json"{{A.hn}}">
</core-ajax>
A
De
una
manera
declara2va
se
exponen
los
datos
de
una
solicitud
AJAX
incluyendo
la
función
que
ges2onará
la
respuesta
cuando
ésta
se
haya
obtenido
hn

48. @javiervelezreye
48
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Expresa
las
colaboraciones
entre
componentes
al
mayor
nivel
de
abstracción
posible.
De
esta
manera
se
dará
cobertura
par2cipa2va
a
un
mayor
número
de
variantes.
Al
definir
un
componente
en
un
nivel
de
abstracción
dado
se
condiciona
su
número
de
potenciales
colaboradores.
Si
el
nivel
aumenta
dicho
número
también.
Opera
Al
Mayor
Nivel
De
Abstracción
Posible
Como
ejemplo
seleccionaremos
de
nuevo
el
componente
core-­‐selec2on
y
lo
compararemos
con
otro
hipoté2co
definido
a
un
nivel
más
abstracto.
core-select
<wc-data-holder>
</wc-data-holder>
data
Al
subir
el
nivel
de
abstracción
en
el
que
se
define
el
contrato
del
componente,
éste
no
queda
restringido
a
escenarios
se
selección
sino
a
cualquier
situación
de
cambio
de
estado
<core-selection>
</core-selection>
select
wc-data
Abstracción
Abstracción
Al
subir
el
nivel
de
abstracción
aumenta
el
número
de
componentes
compa2bles

49. @javiervelezreye
49
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Durante
la
fases
de
diseño
y
análisis
establece
las
abstracciones
de
datos
per2nentes
que
serán
elementos
de
intercambio
en
las
comunicaciones
entre
componentes.
Además
de
definir
el
entramado
de
componentes
de
dominio
es
importante
establecer
las
abstracciones
de
datos
que
permiten
a
éstos
comunicarse.
Construye
Abstracciones
La
familia
de
componentes
google-­‐map-­‐*
es
un
ejemplo
de
librería
que
u2liza
un
objeto
map
para
comunicar
unos
compo-­‐
nentes
con
otros.
{{x}}
data
B
event (ctx)
Se
define
la
abstracción
de
datos
data
que
se
u2liza
para
comunicar
A
con
B
en
los
parámetros
de
una
llamada
Se
definen
la
abstracción
de
datos
del
contexto
de
evento
que
permite
a
A
comunicase
con
los
escuchadores
Bs
Se
definen
la
abstracción
de
datos
de
la
variable
compar2da
x
que
sirve
para
comunicar
los
componentes
Bs
A
A
<google-map map="{{map}}">
</google-map>
<google-map-directions map="{{map}}"
startAddress="San Francisco"
endAddress="Mountain View">
</google-map-directions>
<google-map-search map="{{map}}"
query="Pizza"
result="{{result}}">
</google-map-search>
El
objeto
{{map}}
es
una
abstracción
de
datos
que
representa
un
mapa
de
Google
Maps

50. @javiervelezreye
50
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Define
componentes
abstractos
que
iden2fiquen
un
modelo
de
capacidades
y
comportamiento
protorpico
para
que
otros
componentes
puedan
adquirirlo
por
herencia.
La
definición
de
un
componente
abstracto
que
es
extendido
por
herencia
permite
centralizar
cierta
lógica
común
que
debe
ser
conferida
a
cada
hijo.
Abstrae
Por
ProtoRpos
Un
buen
ejemplo
de
abstracción
por
herencia
que
persigue
este
obje2vo
lo
encontramos
en
componentes
que
heredan
de
core-­‐selector.
C
D
A
B
En
este
nivel
de
abstracción
A
concentra
toda
la
lógica
común
de
que
deberá
disponer
cada
hijo
Cada
hijo
adquiere
las
propiedades,
semán2ca
y
comportamiento
del
padre
core-­‐menu
paper-­‐tabs
core-­‐selector
core-­‐pages
Core-­‐selector
es
un
componente
abstracto
que
define
el
contrato
de
todo
proveedor
de
selección
Cada
hijo
adquiere
la
lógica
del
padre
ya
que
es
una
variante
de
core-­‐
selector
y
se
comporta
como
él

51. @javiervelezreye
51
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Cuando
diseñes
un
componente
define
los
requisitos
sobre
los
contratos
de
los
componentes
de
la
vecindad
que
éstos
deben
sa2sfacer
para
que
puedan
operar
con
él.
Para
operar
con
un
componente
generalmente
basta
con
exigir
que
los
colaboradores
implementen
cierto
contrato
parcial.
Abstrae
Por
Roles
Un
ejemplo
de
abstracción
por
roles
lo
encontramos
en
el
componente
core-­‐
pages.
[play,
stop]
playlist
No
importa
si
los
elementos
de
playlist
son
videos,
audios
u
otra
cosa.
Simplemente
es
preciso
que
dispongan
del
contrato
play
&
stop
<wc-player>
<video> ... </video>
<audio> ... </audio>
<audio> ... </audio>
<video> ... </video>
</wc-player>
wc-­‐player
El
componente
debe
implementar
los
métodos
play
&
stop
<core-pages selected="{{s}}">
<div>Page 1</div>
<div>Page 2</div>
<div>Page 3</div>
</core-pages>
Las
e2quetas
anidadas
representan
las
páginas
ges2onadas.
Pueden
ser
cualquier
elemento.
Sólo
deben
responder
a
eventos
tap

52. @javiervelezreye
52
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Cada
vez
que
definas
una
abstracción
considera
qué
variantes
polimórficas
específicas
existen
dentro
del
dominio
para
cumplir
con
ella.
La
abstracción
permite
definir
puntos
dentro
de
la
arquitectura
donde
diversos
componentes
pueden
ser
intercambiados
para
jugar
un
determinado
rol.
Define
Variantes
Polimórficas
Un
contraejemplo
de
abstracción
por
variantes
lo
encontramos
en
las
e2quetas
core
de
ges2ón
de
iconos.
m
m
m
m
C
B
A
D
Los
componentes
B
y
C
son
variantes
polimórficas
que
pueden
colaborar
con
D
ya
que
heredan
el
contrato
definido
por
A
m
m
A B C
[m]
Los
componentes
A
y
B
son
variantes
polimórficas
que
pueden
colaborar
con
C
ya
que
implementan
el
método
m
que
éste
requiere
core-­‐iconset-­‐svg
core-­‐meta
core-­‐iconset
Core-­‐meta
confiere
a
sus
hijos
un
modelo
de
comunicación
basado
en
el
acceso
a
memoria
compar2da
Aquí
se
u2liza
la
herencia
exclusivamente
como
método
de
factorización
de
código
y
no
como
soporte
a
la
definición
de
variantes
intercambiables.
No
se
puede
decir
que
ninguno
de
los
componentes
hijo
mantengan
una
relación
semán2ca
es-­‐un
con
el
padre

53. @javiervelezreye
53
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
En
el
ejercicio
de
división
de
responsabilidades
orienta
los
procesos
de
abstracción
para
maximizar
las
posibilidades
composi2vas
con
otros
componentes
del
entorno.
Diseñar
al
nivel
adecuado
de
abstracción
permite
hacer
una
división
de
responsabi-­‐
lidades
sobre
el
dominio
que
fomenta
las
oportunidades
de
composición.
Abstrae
Para
Componer
El
componente
core-­‐selec2on
está
definido
a
un
nivel
de
abstracción
elevado
para
dar
soporte
a
muchos
escenarios
de
uso.
Dominio
composición
Análisis
abstracto
Cuando
definas
un
componente
considera
el
nivel
de
abstracción
al
que
debes
definir
su
contrato
para
maximizar
sus
posibilidades
composi2vas
A
core-select
<core-selection>
</core-selection>select
Core-­‐selec2on
no
impone
restricciones
sobre
el
2po,
comportamiento
o
forma
de
operar
de
los
clientes
A
Core-­‐selec2on
recibe
no2ficaciones
de
cambio
de
estado
mediante
el
método
select
y
lo
propaga
por
eventos

54. @javiervelezreye
54
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
En
el
ejercicio
de
división
de
responsabilidades
orienta
los
procesos
de
abstracción
teniendo
en
cuenta
las
necesidades
protorpicas
que
demanden
otros
componentes
en
el
dominio.
Pese
a
que
es
buena
prác2ca
perseguir
el
agnos2cismo
entre
componentes
resulta
pragmá2co
atender
en
la
medida
de
lo
posible
las
necesidades
de
la
vecindad.
Abstrae
Para
Descomponer
Core-­‐selector
es
un
componente
similar
a
core-­‐selec2on
preparado
para
aquellos
escenarios
en
los
que
los
proveedores
de
selección
se
anidan
dentro
del
compo-­‐
nente.
Dominio
descomposición
Factorización
de
variantes
Cuando
definas
un
componente
considera
las
demandas
que
imponen
los
escenarios
protorpicos
de
uso
para
establecer
el
nivel
de
abstracción
del
mismo
<core-pages selected="{{s}}">
<div>Page 1</div>
<div>Page 2</div>
</core-pages>
core-­‐selector
core-­‐pages
Core-­‐pages
hereda
de
core-­‐selector.
Este
componente
funciona
como
core-­‐selec2on
pero
está
preparado
para
aquellos
casos
donde
los
componentes
que
cambian
el
estado
son
los
elementos
agregados
en
el
light
DOM
core-select

55. @javiervelezreye
55
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Durante
las
fases
de
diseño
establece
dis2ntos
niveles
de
abstracción
para
fomentar
la
libertad
evolu2va
de
los
componentes
en
el
marco
de
tu
dominio.
La
definición
de
abstracciones
permite
ar2cular
puntos
de
extensión
variante
donde
nuevos
componentes
puedan
incluirse
como
sus2tutos.
Abstrae
Para
Extender
En
la
librería
core-­‐*
encontramos
varios
componentes
que
heredan
de
core-­‐
selector.
Nuevos
componentes
similares
deberían
también
heredar
de
él.
C
B
A
…
Cada
herencia
polimórfica
supone
un
punto
de
extensión
potencial
para
añadir
futuras
variantes
que
se
adscriban
al
contrato
definido
por
A
A
define
un
contrato
al
que
se
adscriben
todos
sus
hijos
core-­‐menu
core-­‐pages
core-­‐selector
core-­‐grid
Si
algún
día
se
crea
un
componente
para
hacer
grid
de
contenidos
con
un
comportamiento
similar
a
core-­‐pages
o
core-­‐menu
tendría
sen2do
hacerlo
heredando
de
core-­‐selector

56. @javiervelezreye
56
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Diseña
tus
componentes
al
nivel
de
abstracción
adecuado
para
permi2r
que
éstos
puedan
operar
entre
sí
con
suficiente
desacoplamiento.
Cuando
definimos
puntos
de
extensión
por
abstracción
estamos
garan2zando
un
desacoplamiento
entre
los
par2cipantes.
Abstrae
Para
Desacoplar
Un
ejemplo
de
abstracción
que
fomenta
el
desacoplamiento
lo
encontramos
en
la
jerarquía
de
herencia
de
core-­‐selector
dentro
de
la
librería
core-­‐*.
C
B
A
Los
componentes
B,
C
pueden
discrecionalmente
sus2tuir
a
A
en
la
colaboración
con
E
A
define
un
contrato
al
que
se
adscriben
todos
sus
hijos
E
Dado
que
E
no
es
consciente
con
qué
variante
de
A
está
operando
en
cada
momento,
se
ha
establecido
un
desacoplamiento
entre
E
y
sus
colaboradores
core-­‐menu
core-­‐pages
core-­‐selector
Dado
que
ambos
componentes
implementan
el
contrato
definido
en
core-­‐selector,
A
puede
asumir
siempre
la
existencia
de
un
atributo
selected
A
selected

57. @javiervelezreye
57
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
§ Facilitar
el
desarrollo
evolu2vo
§ Aumentar
la
versa2lidad
composi2va
§ Favorecer
la
organización
del
dominio
§ Promover
la
economía
de
Código
§ Fomentar
la
factorización
de
Código
§ Simplificar
el
uso
de
componentes
§ Fomentar
la
declara2vidad
Análisis
&
Diseño
de
Dominio
Diseño
de
Componentes
ObjeRvos
Fases
Contrato
de
Componentes
Región
Al
definir
los
componentes
al
nivel
de
abstracción
adecuado
se
consigue
que
éstos
puedan
operar
en
el
mayor
número
posible
de
contextos
de
uso.
MoRvación
Librería
Dominio
Contrato
de
Componentes

58. @javiervelezreye
58
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Los
componentes
más
abstractos
presentan
mayor
grado
de
reuDlización
potencial
La
factorización
del
código
por
abstracción
permite
centralizar
los
desarrollos
y
evolucionar
por
extensión
Dom
Aco
Est
Com
Adp
Evo
Enc
Std
Ctx
La
búsqueda
sistemáDca
de
componentes
al
nivel
adecuado
de
abstracción
facilita
la
división
de
responsabilidades
Reu
Abs
Trabajar
con
los
niveles
adecuados
de
abstracción
favorece
la
estandarización
Encontrar
las
abstracciones
adecuadas
fomenta
la
encapsulación
de
las
mismas
Encontrar
las
abstracciones
adecuadas
favorece
la
composiDvidad
polimórfica
Tensiones

59. @javiervelezreye
59
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
Abstracción
Add
Alarm
anima2on
hhp://goo.gl/pzh5vW
Este
componente
captura
una
experiencia
de
usuario
que
se
abstrae
de
los
detalles
de
contenido
Todos
los
componentes
de
esta
interfaz
operan
en
un
nivel
de
abstracción
común
Esta
composición
parDcular
de
contenidos
se
ha
encontrado
a
parDr
de
una
descomposición
inicial
del
dominio
El
componente
de
animación
es
un
presentador
de
información
independientemente
de
que
en
este
contexto
se
use
para
configurar
una
alarma
Ejemplo

60. @javiervelezreye
60
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
ReuRlización
Reu2lización
Arquitecto
&
Desarrollador
de
Componentes
Nombre
Actores
Asegúrate
de
maximizar
siempre
las
posibilidades
de
reu2lización
de
tus
componentes
dentro
del
dominio
al
que
pertenecen.

61. @javiervelezreye
61
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
ReuRlización
Antes
de
empezar
a
desarrollar
un
componente
estudia
todos
los
requisitos
que
te
exigen
los
componentes
de
la
vecindad
en
los
diferentes
contextos
de
uso
potencial.
Habrá
muchos
componentes
que
aún
no
existan
cuando
diseñes.
Tu
componente
será
más
reu2lizable
cuanta
mayor
cobertura
a
posibles
requisitos
ofrezca.
EnRende
A
Tus
Clientes
Como
ejemplo
de
esta
faceta
podemos
considerar
el
modelo
arquitectónico
que
permite
construir
e2quetas
como
core-­‐
pages,
paper-­‐tabs
y
core-­‐menu.
r1 r3
r2
r2 r3
B
C
D
r1 r2 r3
Los
componentes
de
la
vecindad
B,
C
y
D
condicionan
las
capacidades
que
debe
ofrecer
el
componente
A
A
core-­‐menu
paper-­‐tabs
core-­‐selector
core-­‐selecRon
core-­‐pages
usa
Core-­‐selector
es
una
adaptación
arquitectónica
de
core-­‐
selec2on
dirigida
a
dar
respuesta
a
las
necesidades
de
no2ficación
de
cambio
que
requieren
core-­‐pages,
core-­‐
tabs
y
core-­‐menu
entre
otros
Core-­‐selec2on
ofrece
un
mecanismo
de
no2ficación
de
cambio
de
una
selección

62. @javiervelezreye
62
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
ReuRlización
Modula
la
demanda
de
requerimientos
de
tus
clientes
con
las
restricciones
impuestas
por
la
división
de
responsabilidades
que
has
hecho
en
el
marco
de
tu
dominio.
La
creación
de
nuevos
compontes
deberá
estar
siempre
en
claro
alineamiento
con
las
estrategias
de
división
de
responsa-­‐
bilidades
establecidas
en
el
dominio.
Respeta
El
Dominio
Un
claro
ejemplo
de
esta
faceta
lo
encontramos
en
la
e2queta
core-­‐header-­‐
panel.
Dominio
r1 r2 r3
Los
requerimientos
de
los
componentes
cliente
B,
C
y
D
no
deben
desestabilizar
al
componente
A
dentro
del
dominio
Espacio
de
responsabilidad
B
A
C D
<core-header-panel>
<div class="core-header">...</div>
<div class="content" fit>...</div>
</core-header-panel>
El
componente
proporciona
un
layout
de
contenidos
usado
por
otros
componentes
especialmente
en
contextos
de
móvil
Sin
embargo
su
comportamiento
no
se
ve
influencia
por
el
comportamiento
ni
las
necesidades
par2cularidades
de
los
componentes
clientes
que
se
agregan
dentro
de
él

63. @javiervelezreye
63
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
ReuRlización
Durante
las
ac2vidades
de
diseño
y
desarrollo
de
componentes
no
cedas
a
las
demandas
que
los
demás
componentes
cliente
puedan
hacer
puntualmente
en
cada
contexto
de
uso.
Cualquier
extensión
del
contrato
debe
ser
some2da
a
un
riguroso
análisis.
El
contrato
debe
responder
a
criterios
de
dominio
y
no
a
necesidades
de
cliente.
Mantén
La
Equidistancia
Para
ilustrar
la
equidistancia
de
cliente
podemos
retomar
el
ejemplo
de
abstracción
de
core-­‐selec2on
que
presentamos
antes.
r1 r2 r3
r1' r2 r3'
Lo
que
demandan
los
clientes
B,
C
y
D
es
tenido
en
cuenta
pero
reformulado
para
definir
las
capacidades
y
comportamiento
de
A
core-select
<wc-data-holder>
</wc-data-holder>
data
<core-selection>
</core-selection>
select
wc-data
Al
expresar
el
contrato
del
componente
a
mayor
nivel
de
abstracción
se
man2ene
una
mayor
distancia
de
los
contextos
de
uso
lo
que
fomenta
la
reu2lización

64. @javiervelezreye
64
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
ReuRlización
Cuando
diseñes
componentes
centra
tu
atención
en
definir
un
contrato
desacoplado
de
la
tecnología
y
decisiones
de
implementación
subyacentes.
Todo
2po
de
acoplamiento
de
contrato
es
un
síntoma
de
mal
diseño
que
compromete
la
reu2lización
del
componente.
Desacopla
Tu
Contrato
Las
e2quetas
core-­‐anima2on-­‐*
son
un
buen
ejemplo
de
componentes
que
presenta
un
alto
acoplamiento
a
tecnología.
lib.js
Plataforma
El
acoplamiento
a
plataforma
es
perjudicial
pero
más
leve
ya
que
todos
los
componentes
operan
sobre
la
misma
plataforma
usa
El
acoplamiento
de
contrato
a
implementación
pone
en
peligro
la
evolu2vidad
El
acoplamiento
a
depen-­‐
dencia
externa
compro-­‐
mete
el
mantenimiento
El
acoplamiento
a
tecnolo-­‐
gía
poluciona
el
desarrollo
y
compromete
la
reu2lización
Este
conjunto
de
e2quetas
expone
todos
los
detalles
del
modelo
de
animación
CSS
sin
realizar
ninguna
abstracción
más
ni
aportar
mayor
valor
<core-animation id="fadeout" duration="500">
<core-animation-keyframe>
<core-animation-prop name="opacity" value="1">
</core-animation-prop>
</core-animation-keyframe
<core-animation-keyframe>
<core-animation-prop name="opacity" value="1">
</core-animation-prop>
</core-animation-keyframe>
</core-animation>

65. @javiervelezreye
65
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
ReuRlización
Una
buena
forma
de
conseguir
un
alto
grado
de
reu2lización
en
el
ámbito
de
tu
dominio
es
asegurar
el
comportamiento
autónomo
de
los
componentes.
El
acoplamiento
es
el
gran
enemigo
de
la
reu2lización.
Idealmente
e2quetas
que
no
presentan
relaciones
de
dependencia
ofrecen
alta
reu2lización.
Persigue
La
Autonomía
Ya
presentamos
en
el
principio
de
acoplamiento
débil
algún
ejemplo
de
autonomía.
No
obstante
en
Polymer
hay
muchas
opciones
para
ilustrar
esta
faceta.
Si
bien
la
autonomía
permite
alcanzar
cotas
altas
de
reu2lización
no
hay
que
olvidar
que
la
construcción
basada
en
componentes
se
fundamenta
en
relaciones
de
composición
<google-hangout-button>
</google-hangout-button>
<google-streetview-pano
panoid="VsCKIVGfvpEAAAQJKfdW1w"
heading="330"
pitch="-2"
zoom="0.8"
disableDefaultUI>
</google-streetview-pano>
Se
u2liza
para
incluir
un
botón
que
arranca
Google
hangouts
Una
bonita
panorámica
de
las
montañas
Machu
Pichu
en
Perú

66. @javiervelezreye
66
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
ReuRlización
Durante
el
desarrollo
de
soluciones
composi2vas
asegúrate
de
que
el
nivel
de
granularidad
no
resulta
demasiado
grande
como
para
comprometer
su
valor
reu2lizable.
El
nivel
de
granularidad
que
alcanza
un
componente
por
sucesivas
encapsula-­‐
ciones
puede
llegar
a
poner
en
riesgo
su
capacidad
de
reu2lización.
Vigila
La
Granularidad
Para
ilustrar
el
significado
de
los
umbrales
de
contexto
y
reu2lización
selecciona-­‐
remos
algunos
ejemplos
de
componentes
en
cada
región.
Umbral
de
reuRlización
Umbral
de
contexto
Por
debajo
del
umbral
de
reu2lización
el
compo-­‐
nente
aún
resulta
reusable
Por
encima
del
umbral
de
contexto
el
componente
ya
2ene
un
significado
contextual
core-image
core-icon, core-iconset
core-ajax, core-meta
Los
componentes
presentan
una
alrsima
reu2lización
pero
no
2enen
gran
significado
contextual
u
v
w u
core-pages, core-menu
paper-tabs, paper-fab
core-drawer-panel
Los
componentes
presentan
alta
reu2lización
y
además
2enen
un
contexto
de
aplica-­‐
ción
claro
v
google-map
google-chart
google-youtube
Los
componentes
están
dedi-­‐
cados
a
un
dominio
tan
espe-­‐
cífico
que
su
capacidad
de
reu2lización
es
menor
w

67. @javiervelezreye
67
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
ReuRlización
En
la
medida
de
lo
posible,
construye
componentes
que
puedan
operar
exclusivamente
a
par2r
de
la
configuración
semán2ca
que
reciben
desde
el
marcado
HTML.
Las
e2quetas
que
deben
ser
configuradas,
compuestas,
adaptadas
o
explotadas
mediante
la
inclusión
de
código
presentan
un
nivel
de
reu2lización
menor.
Persigue
La
DeclaraRvidad
Un
contraejemplo
del
uso
del
diseño
declara2vo
lo
encontramos
en
la
e2queta
core-­‐a11y-­‐keys.
Desarrollador
Web
Maquetador
Web
Maquetador
Web
Los
componentes
que
se
instancian
declara2vamente
son
cómodos
y
fáciles
de
usar
Los
componentes
que
requieren
configuración
o
código
pegamento
hacen
más
improbable
su
uso
Js
<core-a11y-keys
target="{{}}"
keys="up down left right"
on-keys-pressed="{{hn}}">
</core-a11y-keys>
Este
componente
puede
resultar
de
gran
u2lidad
prác2ca.
Sin
embargo
el
hecho
de
requerir
definir
una
función
manejadora
en
JavaScript
compromete
su
reu2lización
ya
que
exige
de
competencias
programá2cas
al
usuario
hn
La
e2queta
core-­‐a11y-­‐keys
proporciona
un
mecanismo
para
procesar
eventos
de
teclado

68. @javiervelezreye
68
Principios
de
Diseño
Principios
de
Diseño
en
Componentes
Web
Principio
de
ReuRlización
En
la
medida
de
lo
posible
evita
establecer
convenios
de
desarrollador
porque
limitan
su
aplicabilidad
al
ámbito
personal
y
reducen
las
posibilidades
de
reu2lización.
Cuando
los
convenios
no
2enen
una
amplitud
de
aceptación
considerable
pueden
suponer
un
problema
para
el
cliente.
Reduce
Los
Convenios
Presentaremos
ejemplos
rpicos
de
convenios
usados
por
desarrolladores.
El
propósito
es
meramente
ilustra2vo
y
no
prescrip2vo.
Plataforma
Equipo
Tu
Tus
convenciones
de
diseño
y
desarrollo
se
convierten
en
restricciones
para
otros
usuarios
Al
menos
deberías
alinear
tus
criterios
de
estandarización
con
tu
organización
o
equipo
de
trabajo
my_variable
MyMethod
init()
myVariable
myMethod
constructor()
<myWebCompoment>
myColor = "blue"
isVisible = "true"
<my-web-component>
my-color = "blue"
visible