CoolChat

El sitio web puede ser accedido haciendo click aquí. IMPORTANTE: Clickear exactamente ese link (contiene https:// al principio y sin www) porque esa es la ruta del sitio que Netlify nos da. Si se le agrega www o se modifica el link, va a dar Page Not Found.

Principales tecnologías (y demás)

• React v16.3.2
• Redux v4.0.0
• Graphcool
• GraphQL
• Apollo
• Netlify

Decisiones de diseño (UI)

• Utilizamos CSS Modules para administrar las clases CSS asociadas a componentes. Por esta razón, el CSS del proyecto se maneja de manera diferente a la habitual: Webpack se encarga de cambiar el nombre de las clases CSS de los archivos de forma de evitar colisiones de nombre, y para utilizar una clase CSS debe ser importado el archivo CSS dentro del archivo JS y las clases accedidas como propiedades del objeto importado.

• CoolChat sigue también los principios del Responsive Web Design para lograr que la renderización de la página sea óptima en una gran variedad de tamaños de pantalla. Con esto intentamos lograr: ubicuidad, flexibilidad, performance, optimización y que además la página se vea bien en dispositivos futuros. Para lograr esto utilizamos varios de los conceptos dados en clase, como ser: flow, nesting, unidades relativas, tamaños máximos y mínimos, entre algunos otros.

• No nos guíamos por ningún UI Kit del estilo de Material-UI ya que optamos por no acoplarnos a un diseño particular porque deseábamos definir un estilo propio, moderno y atractivo, pero sin estar atados a nada, para así poder diseñar libremente. Para esto, utilizamos una paleta de colores elegida por nosotros así como también una estructura de componentes que nos permitió diseñar una web agradable a la vista.

• Tuvimos siempre a la vista los conceptos de eficacia, eficiencia y satisfacción, así como también tuvimos en vista el tiempo de aprendizaje, tasa de errores, retención en el tiempo, satisfacción subjetiva, entre otros conceptos, para lograr una buena Usabilidad. Logramos de esta manera tener una web útil (usable y además funcional).

• Finalmente, también utilizamos lo aprendido sobre percepción y principios Gestalt al utilizar especialmente el principio Pragnanz (simplicidad) y el concepto de frente y fondo.

Otras decisiones y cosas importantes

• Utilizamos create-react-app, que es un generador estático de código para evitar el setup repetitivo de apliaciones de este tipo.

• No utilizamos subscriptions ya que no logramos configurarlas del todo, por lo que hicimos uso de Query's que realizan polling cada 0.5 segundos, para así lograr el aspecto de tiempo real de una aplicación de chat como esta.

• Comenzamos con un esquema de backend bastante más complicado, pero que iba a hacer bastante eficiente la web. Lamentablemente, nos vimos un poco superados por la dificultad de las queries y mutations, ya que teníamos relaciones bastante más complicadas de las que terminamos teniendo y no encontramos o no supimos buscar ejemplos de este tipo de queries o mutations, por lo que decidimos priorizar el resto de la web y dejar un backend más simple, menos eficiente pero funcional. Para la segunda entrega, con más tiempo y ya más experiencia, estaría bueno intentar volver a la idea de backend previa e intentar optimizarlo. El esquema final del backend puede verse aquí mismo en la documentación.

• Utilizamos librerías de terceros (como ser react-emojify y react-microlink, por nombrar dos de ellas), para ayudarnos a implementar algunas de las funcionalidades pedidas.

• Notamos que a veces el backend demora en responder, especialmente a las primeras llamadas. Probablemente sea debido a que estamos usando el plan gratuito de graphcool y el servidor hace un cold start o algo por el estilo en las primeras llamadas. Aclaramos esto por las dudas de que se perciba alguna lentitud o cuelge. Una vez pasadas las primeras llamadas al servicio esta lentitud se va.

• No llegamos a implementar: la notificación de usuario escribiendo y la versión mobile del sitio web, por razones de falta de tiempo de nuestro lado. El resto del obligatorio se completó de manera satisfactoria.

Jerarquía de Componentes

Optamos por una jerarquía que fomente la creación de componentes reusables a futuro, intentando desligar lo más posible unos de otros. Dentro del directorio src se encuentran las principales divisiones del sistema como ser pages, query, routes, store, etc… Entrando un poco más en detalle, decidimos crear un directorio pages para las vistas principales del sistema, que es la vista Home y la de Chat. Agregamos una última vista Not Found para todas las rutas que no coincidan con las vistas anteriormente descritas para darle información al usuario sobre su error.

El directorio de Chat también se encuentra dividido en sub directorios ya que está compuesto por un componente MessageHistory y un componente NewMessage. Aquí es donde empezamos a ver la descomposición en componentes a lo largo de todo el proyecto, ya que si nos seguimos adentrando en estos sub directorios nos damos cuenta que sigue sucendiendo lo mismo: MessageHistory está conformado por un componente HeaderConversation y MessageCard.

Al principio dudamos sobre ubicar estos componentes en un directorio aparte llamado components, pero decidimos que moveríamos el componente una vez que nos diéramos cuenta que lo precisábamos en algún otro lugar. Como conclusión, todos los componentes quedaron anidados ya que en ningún momento se precisó de ninguno desde otro lugar. Confiamos en que es una buena práctica generalizar solo cuando se ve necesario ya que así es mucho más simple seguir la lectura de los componentes y entender la división de jerarquías.
En el directorio de query se encuentra un archivo con todas las queries gql que creimos necesarias desde el principio del proyecto. Decidimos centralizar esta información en un solo directorio por si en el futuro se implementa con otra librería, haciéndolo mantenible y escalable.

Otro directorio a destacar es el de routes, que cuenta con una un archivo base en donde se crean los componentes Route y otro en donde se especifica el path y el componente a mostrar. Nos pareció que era una manera sencilla de centralizar la creación de nuevas rutas, ya que para agregar una ruta solo se debe agregar un objeto al archivo routes.js y no hay que preocuparse por componentes de React.

Optamos por crear un archivo index.js en cada uno de estos directorios para hacer más sencilla la importación del mismo ya que, de no existir este archivo, el import seria repetitivo y daría lugar a mas errores de distracción.

A su vez, a lo largo de todo el proyecto aplicamos Container Components Pattern en cada ocasión que vimos oportuna, creando así un sistema reusable.

Redux - Estructura del estado interno

Decidimos guardar con Redux la información que no viene directamente de nuestro backend o aquella que vamos a necesitar a lo largo de toda la experiencia de usuario. Es por esto que nuestro Store cuenta con dos Reducers, uno para guardar los datos referidos al usuario logueado y otro referido a la contraparte del chat. También se crearon las acciones pertinentes para modificar estos Reducers, con sus actions constants.

También tomamos la decisión de guardar el tema del sitio en la base de datos para que sea persistido, pero a su vez lo almacenamos en el Store del usuario para hacer un rápido cambio cuando el usuario así lo desee.

Esquema del Backend

Si bien el esquema del backend (y el código entero del backend) se encuentra en la carpeta llamada backend, incluímos aquí el esquema que definimos para el mismo:

type User @model {
  id: ID! @isUnique
  username: String!
  photoUrl: String
  state: State! @defaultValue(value: ONLINE)
  lastDisconnection: DateTime
  theme: Theme! @defaultValue(value: LIGHT)
  writing: Boolean! @defaultValue(value: false)
}

type Message @model {
  id: ID! @isUnique
  text: String!
  to: String!
  from: String!
  date: DateTime
}

enum State {
  ONLINE,
  OFFLINE
}

enum Theme {
  DARK,
  LIGHT
}

Deploy en Netlify

Si bien está incluído en el repositorio, colocamos aquí también el archivo mediante el cual Netlify hace deploy automático de nuestra web en cada push a la rama develop:

[build]
  base    = "coolchat/"
  publish = "coolchat/build/"
  command = "npm run build"

[context.deploy-preview.environment]
    HUGO_VERSION = "0.40.2"

[context.production]
  command = "npm run build"
  [context.production.environment]
    REACT_APP_GRAPHQL_URI = "https://api.graph.cool/simple/v1/cjgttpzdk37pu0175kbe87tgi"

Instrucciones para configurar un nuevo ambiente de desarrollo

Para configurar un nuevo ambiente de desarrollo (frontend) deben seguirse los siguientes pasos (utilizando npm):

• Dirigirse hasta la carpeta del repositorio (CoolChat-Curzio-Ferrari) con la consola.
• Una vez allí ejecutar el comando cd coolchat.
• Luego ejecutar npm install.
• Finalmente, ejecutar npm start, y la aplicación se iniciará localmente.

Para hacer deploy de cambios en el backend deben seguirse los siguientes pasos:

• Dirigirse hasta la carpeta del repositorio (CoolChat-Curzio-Ferrari) con la consola.
• Una vez allí ejecutar el comando cd backend.
• Luego de hacer los cambios en el esquema o los resolvers, ejecutar graphcool deploy.