docs: la guia escrita como notas, sin adornos

This commit is contained in:
SITO 2026-10-19 13:17:28 +02:00
parent abae8132a4
commit 5bce7d38ed
3 changed files with 158 additions and 198 deletions

View file

@ -1,218 +1,180 @@
# Guía de desarrollo de OASIS_MOBILE # Guía de desarrollo
**Léela antes de tocar nada.** Esta rama vive encima de Oasis, que desarrolla Notas para quien vaya a meter mano en la rama del móvil. Leedlas antes de empezar,
epsylon (el dev) y que saca una versión casi cada día. Todo lo que añadimos tiene que nos ahorramos disgustos.
que sobrevivir a la siguiente versión sin reescribirlo. Esta guía dice qué se puede
tocar, qué no y cómo hacer cada tipo de cambio.
Las cifras y el razonamiento están en Esta rama va encima de Oasis, que es de epsylon. Él saca versión casi cada día
[docs/FRONTERA_UPSTREAM.md](docs/FRONTERA_UPSTREAM.md). Aquí solo van las reglas. (39 entre la 1.0.1 y la 1.3.3, en siete semanas) y cada versión llega en un solo
commit. Si metemos cosas en sus ficheros, en cada integración hay que volver a
pelearse con ellas. Por eso la idea es sencilla: lo de Oasis lo cambia él; nosotros
cambiamos cómo se ve y se usa en el móvil, y lo hacemos en ficheros nuestros.
--- Los números y de dónde salen están en `docs/FRONTERA_UPSTREAM.md`.
## 1. La regla de oro
> **Oasis lo cambia el dev. Nosotros cambiamos cómo se ve en el móvil.** ## Lo que no se toca
>
> Lo que la rama añade va en **ficheros nuestros**. En un fichero del dev, como mucho,
> **una línea que llama a un fichero nuestro**, y solo en el móvil.
¿Por qué? Entre la 1.0.1 y la 1.3.3 (siete semanas) el dev publicó 39 versiones, cada - `src/backend/backend.js`. Cambia en 34 de cada 39 versiones. Ni rutas nuevas, ni
una en un único commit. `backend.js` cambió en 34 de ellas, `main_views.js` en 31, middleware, ni envolver funciones suyas como `checkMod`.
las traducciones en 31. Cada línea nuestra en esos ficheros es un conflicto casi - La cadena de middleware del final de `backend.js`. Crece en cada versión.
seguro en la próxima integración. Y si tocamos cómo se publica o se cuenta algo en la - Los modelos de `src/models/`, salvo los nuestros (`karvan_model.js`,
red, nuestro móvil deja de entenderse con los demás nodos. `fork_workflows.js`). Ahí se decide qué se publica en la red y cómo se cuenta.
Si lo cambiamos, nuestro móvil cuenta distinto que el escritorio de al lado. Un
ejemplo real: quien crea una votación no puede votar en ella. No nos gusta, pero
es una regla del modelo, así que se explica en pantalla y punto.
- `src/server/` (arranque de SSB, `ssb_config.js`, `package.json`).
- `src/backend/request_guards.js`, que lleva la CSP. Nada de `style=""` ni de
`<script>` en la página.
- Las traducciones del dev, `translations/oasis_*.js`. Se reescriben casi en cada
versión.
- `styles/style.css` y `styles/mobile.css`.
- Los temas del dev: Dark, Clear, Purple, Matrix y también `OasisMobile.css`, que
aunque parezca nuestro es suyo (lo toca en 21 de 39 versiones).
---
## 2. El semáforo ## Las vistas del dev: una línea y ya
### ROJO: no se toca `src/views/*_view.js` y `main_views.js` son del dev y las reescribe a menudo
(`tribes_view.js` en 23 versiones, `main_views.js` en 31). Si en una pantalla suya
| Qué | Dónde | Por qué | hace falta otro HTML en el móvil, el código va en `src/views/mobile_ui.js` y en la
|---|---|---| vista solo queda la llamada:
| El backend del dev | `src/backend/backend.js` | Cambia en 34/39 versiones. Rutas, middleware, todo. |
| La cadena de middleware | el array `middleware` al final de `backend.js` | Crece en cada versión (contexto por petición, idioma, CSP...). |
| Los modelos del dev | `src/models/*` salvo los nuestros (ver verde) | Definen qué se publica en el log SSB y cómo se cuenta. Cambiarlos rompe la red. |
| El arranque de SSB | `src/server/*` (`SSB_server.js`, `ssb_config.js`, `package.json`) | Dependencias y conexión con la red. |
| La política de seguridad | `src/backend/request_guards.js` | La CSP: sin `style=""` ni `<script>` en línea. Así se queda. |
| Las traducciones del dev | `src/client/assets/translations/oasis_*.js` | Se reescriben en 31/39 versiones. |
| Las hojas del dev | `styles/style.css`, `styles/mobile.css` | Cambian en 32/39 y 10/39. |
| Los temas del dev | `themes/Dark-SNH.css`, `Clear-SNH.css`, `Purple-SNH.css`, `Matrix-SNH.css`, **`OasisMobile.css`** | `OasisMobile.css` es **del dev** (21/39), no nuestro. |
Ejemplos de lo que **no** se hace:
- Cambiar una regla de un modelo, aunque parezca mala. "Quien crea una votación no
vota" está en `votes_model.js`: se explica en pantalla, no se cambia.
- Añadir una ruta o un middleware a `backend.js`.
- Envolver o reescribir una función del backend (`checkMod`, `getConfig`...).
- Editar `oasis_es.js` para cambiar un texto.
- Meter estilos en línea o `<script>` en una vista.
### ÁMBAR: una línea de enganche y nada más
Las **vistas del dev** (`src/views/*_view.js`, `main_views.js`). Se reescriben a
menudo (`tribes_view.js` en 23/39, `main_views.js` en 31/39), así que:
- La lógica va en `src/views/mobile_ui.js` (o en otro `mobile_*.js` nuestro).
- En la vista del dev queda **una llamada**, siempre detrás de la bandera:
```js ```js
// en tribes_view.js (del dev)
const mobileUi = require('./mobile_ui'); const mobileUi = require('./mobile_ui');
... // ...
if (mobileUi.isMobile()) return mobileUi.tribeTabs(tribe, section, sections); if (mobileUi.isMobile()) return mobileUi.tribeTabs(tribe, section, sections);
``` ```
- Si el dev reescribe la vista, se vuelve a poner esa línea. No hay que reconstruir Cuando el dev reescribe la vista, se vuelve a poner esa línea y listo. En escritorio
una función entera. no cambia nada porque la bandera `OASIS_MOBILE` solo la pone `main.js` en el móvil.
- En escritorio (sin `OASIS_MOBILE`) la vista del dev funciona igual que en el
original.
Enganches que hay hoy: `main_views.js` (6), `tribes_view.js` (6), `vote_view.js` (4), Ahora mismo hay enganches en `main_views.js`, `tribes_view.js`, `vote_view.js`,
`settings_view.js` (3), `welcome_view.js` (3). Para encontrarlos: `settings_view.js` y `welcome_view.js`. Para verlos: `grep -n mobileUi src/views/*.js`.
`grep -n mobileUi src/views/*.js`.
### VERDE: nuestro, se toca libremente
| Para qué | Fichero | ## Lo que es nuestro
|---|---|
| Aspecto de los dos skins de móvil (márgenes, letra, botones, piezas nuevas) | `src/client/assets/styles/mobile_ux.css` |
| Colores y formas del skin Acampada | `src/client/assets/themes/Acampada.css`, `styles/hive_acampada.css` |
| Estilos de Karvan | `styles/karvan.css` |
| Piezas de interfaz que se enchufan en vistas del dev | `src/views/mobile_ui.js` |
| Pantallas enteras propias | `src/views/mobile_modules_view.js`, `karvan_view.js`, `identities_view.js` |
| Lanzador, barra de abajo, barra de arriba | `src/views/hive_views.js` |
| Iconos | `src/views/mobile_icons.js` |
| Rutas propias y retoques a respuestas del dev | `src/backend/karvan_routes.js` (el router propio) |
| Workflows propios | `src/models/fork_workflows.js` |
| Modelos propios | `src/models/karvan_model.js` |
| JavaScript de cliente propio | `src/client/public/js/karvan.js` |
| Textos nuevos | `src/client/assets/translations/i18n_fork.js` |
| Imágenes propias | `src/client/assets/images/ux-*.svg` |
| La app Android | `android/` |
--- Aquí se puede hacer lo que haga falta.
## 3. Cómo se hace cada cosa - `src/client/assets/styles/mobile_ux.css`: márgenes, letra, botones y todas las
piezas nuevas. Vale para los dos skins de móvil.
- `src/client/assets/themes/Acampada.css` y `styles/hive_acampada.css`: el skin
Acampada.
- `styles/karvan.css`, `src/views/karvan_view.js`, `src/models/karvan_model.js`,
`src/client/public/js/karvan.js`: Karvan entero.
- `src/views/mobile_ui.js`: lo que se enchufa en vistas del dev.
- `src/views/mobile_modules_view.js`, `identities_view.js`: pantallas propias.
- `src/views/hive_views.js`: lanzador y barras de arriba y abajo.
- `src/views/mobile_icons.js`: los iconos.
- `src/backend/karvan_routes.js`: nuestro router. Va justo delante del del dev.
- `src/models/fork_workflows.js`: nuestros workflows.
- `src/client/assets/translations/i18n_fork.js`: nuestros textos.
- `src/client/assets/images/ux-*.svg`: nuestras imágenes.
- `android/`.
### Cambiar cómo se ve algo
1. Busca la clase en el HTML (servidor local + inspector, ver sección 6).
2. Escribe la regla en `mobile_ux.css`. Los colores, siempre con los tokens `--ux-*`
(`--ux-bg`, `--ux-fg`, `--ux-accent`, `--ux-muted`, `--ux-line`, `--ux-danger`...):
así sale bien en Acampada y en OasisMobile.
3. Si no gana: `mobile.css` y `Acampada.css` usan `!important` y selectores largos.
Sube la especificidad (`.main-column div.x`, `label.x input.y[type="checkbox"]`) y
pon `!important`. Ojo: `Acampada.css` quita el borde a **todos** los `div`; para
ponerle borde a uno, `.main-column div.mi-clase`.
4. Letra: **Anton solo en títulos y en el botón principal negro** (`.create-button`).
Todo lo demás, en la letra del sistema en negrita.
5. Márgenes: uno solo, de 14 px a cada lado. No añadas rellenos a contenedores
intermedios.
### Cambiar el HTML de una pantalla del dev ## Cómo hacer cada cosa
1. Función nueva en `mobile_ui.js`, que reciba lo que necesite como parámetro.
2. Una línea en la vista del dev: `mobileUi.isMobile() ? mobileUi.miPieza(...) : lo_de_antes`.
3. Los textos, por `i18n` (ver "Textos").
### Una pantalla entera nueva, o una ruta nueva Cambiar cómo se ve algo. Se busca la clase en el HTML (servidor local e inspector) y
En el router propio, `src/backend/karvan_routes.js`. Va justo **antes** del router se escribe la regla en `mobile_ux.css`. Para los colores usad las variables `--ux-*`
del dev en la cadena: lo que no atiende pasa al del dev con `next()`. (`--ux-bg`, `--ux-fg`, `--ux-accent`, `--ux-muted`, `--ux-line`, `--ux-danger`), que
tiran de Acampada si está y si no de la paleta de OasisMobile. Si la regla no gana,
es que `mobile.css` o `Acampada.css` mandan con `!important` y selectores largos:
hay que subir la especificidad y poner `!important` también. Ojo con una trampa:
`Acampada.css` quita el borde a todos los `div`, así que para ponérselo a uno hace
falta `.main-column div.la-clase`.
Letra: Anton para títulos y para el botón negro principal de cada pantalla
(`.create-button`). Lo demás, letra del sistema en negrita.
Márgenes: 14 px a cada lado y ya. Los contenedores de en medio sin relleno, que
antes se iban sumando y una ficha perdía 74 px por lado.
Cambiar el HTML de una pantalla del dev. Función en `mobile_ui.js` y una línea en la
vista, como arriba.
Una pantalla o una ruta nueva. En `karvan_routes.js`. Lo que no atiende nuestro
router pasa al del dev con `next()`:
```js ```js
.get('/modules', async (ctx, next) => { .get('/modules', async (ctx, next) => {
if (!isMobile()) return next(); // en escritorio, la del dev if (!isMobile()) return next(); // escritorio: la del dev
ctx.body = mobileModulesView({ ... }); // en el movil, la nuestra ctx.body = mobileModulesView({ ... });
}) })
``` ```
### Retocar lo que responde el dev, sin editarlo Retocar lo que contesta el dev. También en `karvan_routes.js`, en `wrapUpstream`: deja
El envoltorio `wrapUpstream` de `karvan_routes.js` deja actuar al dev y después mira que el dev conteste y luego mira la respuesta. Así sabemos a qué sección apagada se
la respuesta. Así se sabe a qué sección apagada se quería entrar (el dev solo quería entrar (el dev solo manda a `/modules`) o añadimos `?saved=1` al guardar.
redirige a `/modules`) o se añade `?saved=1` tras guardar. Este es el sitio para eso,
nunca `backend.js`.
### Textos Textos. En `i18n_fork.js` y en los 11 idiomas (en, es, fr, eu, de, it, pt, zh, ar,
- Siempre en `i18n_fork.js`, **en los 11 idiomas** (en, es, fr, eu, de, it, pt, zh, hi, ru). Antes, mirad que la clave no exista ya en `oasis_en.js`, porque si existe la
ar, hi, ru). estaríais cambiando también en escritorio. En el código siempre con texto de reserva:
- Comprueba que la clave no existe ya en `oasis_en.js`: si existe, se pisaría también `i18n.miClave || 'My text'`.
en escritorio.
- En el código, siempre con texto de reserva en inglés: `i18n.miClave || 'My text'`.
### Un workflow nuevo Un workflow. En `fork_workflows.js`, que lo mete en las listas que exporta el modelo
En `fork_workflows.js`. Se registra empujándolo a los arrays que exporta el modelo del dev. No se toca `workflows_model.js`.
del dev. No se edita `workflows_model.js` ni se redefine un workflow del dev.
### Un icono Un icono. En `mobile_icons.js`, trazo de 2 px sobre rejilla de 24 y `currentColor`. El
En `mobile_icons.js`: trazo de 2 px en rejilla de 24, `currentColor`. La clave es la nombre es el de la ruta: `/tribes` es `tribes`.
ruta (`/tribes` → `tribes`).
### Algo que solo pasa en el móvil
Siempre detrás de `process.env.OASIS_MOBILE === '1'` (o `mobileUi.isMobile()`).
`main.js` la pone; el escritorio no la tiene.
--- ## Antes de hacer commit
## 4. Antes de cada commit - Que `git diff --stat` no toque nada de la lista de lo que no se toca. En las vistas
del dev, solo líneas de enganche.
- `node --check` en los `.js` que hayáis cambiado.
- Arrancar en local y ver que `/activity`, `/tribes`, `/modules`, `/settings`,
`/votes`, `/karvan` e `/inbox` cargan.
- Mirarlo a 412 px de ancho, y a 360 si es algo ancho.
- Los textos nuevos, en los 11 idiomas.
- Nada en línea, que la CSP lo bloquea.
- Commit en castellano, sin coautorías de herramientas.
- Sin claves, contraseñas ni nada de `.ssb`.
- [ ] `git diff --stat` no toca nada rojo. Si toca una vista del dev, son líneas de
enganche, no funciones.
- [ ] `node --check` en cada `.js` cambiado.
- [ ] El servidor local arranca y responde 200 en `/activity`, `/tribes`, `/modules`,
`/settings`, `/votes`, `/karvan`, `/inbox`.
- [ ] Mirado a 412 px de ancho (y a 360 si es una pieza ancha).
- [ ] Textos nuevos en los 11 idiomas.
- [ ] Nada en línea (`style=""`, `<script>`): la CSP lo bloquea.
- [ ] Commit en castellano, sin rastro de herramientas ni coautorías automáticas.
- [ ] Ninguna clave, contraseña ni `.ssb` en el commit.
--- ## Cuando sale versión nueva del dev
## 5. Cuando sale una versión nueva del dev 1. Lo suyo se coge tal cual.
2. En sus vistas se vuelven a poner los enganches. El `grep -n mobileUi` sobre la
versión anterior de la rama dice dónde iban.
3. Se repite la medición de `docs/FRONTERA_UPSTREAM.md`: qué ha tocado y si ha
desaparecido alguna clase que usen nuestras hojas.
4. Se repasan a 412 px las pantallas de la lista de arriba.
5. Se compila la APK con la oficial de esa misma versión como base
(`android/scripts/release.sh` con `OASIS_APK_BASE`).
1. Coge su código tal cual para todo lo rojo.
2. En las vistas del dev, vuelve a poner los enganches (`grep -n mobileUi`
en la versión anterior de la rama te dice dónde estaban).
3. Repite la medición de [docs/FRONTERA_UPSTREAM.md](docs/FRONTERA_UPSTREAM.md):
qué ficheros ha tocado y si ha desaparecido alguna clase de la que tiran nuestras
hojas.
4. Revisa a 412 px las pantallas de la sección 4.
5. Compila la APK con la oficial de **esa misma versión** como base
(`android/scripts/release.sh`, variable `OASIS_APK_BASE`).
--- ## Probar en local
## 6. Cómo probar
**Servidor local** (con una identidad de usar y tirar y la red en pausa):
```sh ```sh
HOME=/tmp/oasis-prueba OASIS_NETWORK_PAUSED=1 node main.js HOME=/tmp/oasis-prueba OASIS_NETWORK_PAUSED=1 node main.js
# http://localhost:3000, con el inspector del navegador en modo movil, 412x915
``` ```
- `src/server/node_modules` no está en git: hace falta uno (el de la APK base vale). Y en el navegador `http://localhost:3000` con el inspector en modo móvil a 412x915.
Va con una identidad de usar y tirar y con la red parada.
Cosas que pasan:
- `src/server/node_modules` no está en git. Sirve el de la APK base.
- Si al reiniciar sale "Another Oasis instance is already running", el anterior sigue - Si al reiniciar sale "Another Oasis instance is already running", el anterior sigue
vivo y estás viendo código viejo: mátalo antes. vivo y estáis viendo código viejo. Matadlo primero.
- Al arrancar se borran `src/configs/banking-eco-history.json` y - Al arrancar desaparecen `src/configs/banking-eco-history.json` y
`fediverse-accounts.json`: `git checkout -- src/configs/` antes de hacer commit. `fediverse-accounts.json`. Antes del commit, `git checkout -- src/configs/`.
**En el emulador** (Android Studio, `Pixel_9_API_36`): la APK de depuración deja En el emulador (`Pixel_9_API_36` de Android Studio), la APK de depuración deja
inspeccionar la WebView con `chrome://inspect` o con inspeccionar la WebView desde `chrome://inspect`.
`adb forward tcp:9333 localabstract:webview_devtools_remote_<pid>`.
---
## 7. Deuda que queda (por orden) ## Lo que todavía está mal
Cosas de antes de esta guía que todavía la incumplen. Ver la sección 5 de Cosas de antes de estas normas que aún no las cumplen, por orden de lo que más
[docs/FRONTERA_UPSTREAM.md](docs/FRONTERA_UPSTREAM.md). duele:
1. **`OasisMobile.css`** difiere en 4.873 líneas de la del dev. Hay que devolverle la 1. `OasisMobile.css` se parece poco a la del dev: 4.873 líneas distintas. Hay que
suya y llevar nuestra maqueta a una hoja propia. devolverle la suya y pasar nuestra maqueta a una hoja propia.
2. **21 trozos antiguos en `backend.js`** (14 con la bandera de móvil): exportar copia 2. Quedan 21 trozos nuestros en `backend.js` (copia de seguridad, avatar de la barra
de seguridad, avatar de la barra de arriba, vídeos, filtro del lanzador... Pasan al de arriba, vídeos, filtro del lanzador...). Tienen que irse al router propio.
router propio. 3. El workflow `activists` sigue cambiado en `workflows_model.js`. Hay que dejarlo
3. **El workflow "activists"** sigue redefinido en `workflows_model.js`: devolver el del como el del dev; el nuestro ya es `acampada`.
dev (ya existe el nuestro, "acampada"). 4. Selectores que ya no apuntan a nada: 61 en `OasisMobile.css`, 29 en
4. **Selectores muertos** en `OasisMobile.css` (61), `hive_acampada.css` (29) y `hive_acampada.css` y 5 en `Acampada.css`.
`Acampada.css` (5).

View file

@ -13,12 +13,10 @@
> >
> **Los fallos de esta rama se reportan aquí, nunca a epsylon.** > **Los fallos de esta rama se reportan aquí, nunca a epsylon.**
> ## Para desarrollar: lee primero la [GUÍA DE DESARROLLO](GUIA_DE_DESARROLLO.md) Si vas a desarrollar, lee antes la [guía de desarrollo](GUIA_DE_DESARROLLO.md). Ahí
> está qué se puede tocar y qué no. En corto: el backend, el middleware, los modelos y
> Qué se puede tocar y qué no. Resumen: **el backend, el middleware, los modelos y las traducciones son de epsylon y no se tocan; lo nuestro va en hojas, vistas y rutas
> las traducciones son del dev y no se tocan**; lo nuestro va en hojas de estilo, propias.
> vistas y rutas propias, y en las vistas del dev como mucho una línea de enganche.
> El porqué, con cifras: [docs/FRONTERA_UPSTREAM.md](docs/FRONTERA_UPSTREAM.md).
Versión base: **Oasis 1.3.3** · Rama: `PRUEBAS` · Versión base: **Oasis 1.3.3** · Rama: `PRUEBAS` ·
[Documentación completa](https://gitea.laenre.net/hacklab/OASIS_MOBILE/wiki) · [Documentación completa](https://gitea.laenre.net/hacklab/OASIS_MOBILE/wiki) ·
@ -200,13 +198,13 @@ OASIS_APK_BASE=/ruta/oasis-v1.3.3.apk ./scripts/release.sh # compila, verifica
## Documentación ## Documentación
Para desarrollar en la rama, en el propio repositorio: Para desarrollar, en el propio repositorio:
| | | | | |
|---|---| |---|---|
| [GUIA_DE_DESARROLLO.md](GUIA_DE_DESARROLLO.md) | Qué se toca y qué no, cómo hacer cada tipo de cambio, comprobaciones antes de cada commit | | [GUIA_DE_DESARROLLO.md](GUIA_DE_DESARROLLO.md) | Qué se toca, qué no y cómo hacer cada cosa |
| [docs/FRONTERA_UPSTREAM.md](docs/FRONTERA_UPSTREAM.md) | Cómo cambia el dev cada versión, medido, y el plan para sanear la rama | | [docs/FRONTERA_UPSTREAM.md](docs/FRONTERA_UPSTREAM.md) | Cuánto cambia el dev en cada versión, medido |
| [docs/USABILIDAD_PAD.txt](docs/USABILIDAD_PAD.txt) | Pruebas de usabilidad en el móvil: lo arreglado y lo pendiente | | [docs/USABILIDAD_PAD.txt](docs/USABILIDAD_PAD.txt) | Pruebas de usabilidad en el móvil |
Todo lo de arriba, en detalle, está en la Todo lo de arriba, en detalle, está en la
**[wiki](https://gitea.laenre.net/hacklab/OASIS_MOBILE/wiki)**: **[wiki](https://gitea.laenre.net/hacklab/OASIS_MOBILE/wiki)**:

View file

@ -1,7 +1,7 @@
# Frontera con upstream: que se puede tocar y que no # Frontera con upstream: que se puede tocar y que no
> Las reglas para el dia a dia estan en [GUIA_DE_DESARROLLO.md](../GUIA_DE_DESARROLLO.md). Las normas del dia a dia estan en [GUIA_DE_DESARROLLO.md](../GUIA_DE_DESARROLLO.md); esto
> Este documento es la medicion que las justifica. es la medicion de la que salen.
Medido el 19/10/2026 sobre el repositorio del dev (code.03c8.net/krakenslab/oasis), Medido el 19/10/2026 sobre el repositorio del dev (code.03c8.net/krakenslab/oasis),
de la release 1.0.1 (29/08) a la 1.3.3 (18/10), y comparado con la rama PRUEBAS. de la release 1.0.1 (29/08) a la 1.3.3 (18/10), y comparado con la rama PRUEBAS.
@ -10,17 +10,17 @@ contar con `git log --numstat` por fichero.
## 1. Como trabaja el dev ## 1. Como trabaja el dev
- **Una release casi cada dia**: 39 entre la 1.0.1 y la 1.3.3, en siete semanas. - Una release casi cada dia: 39 entre la 1.0.1 y la 1.3.3, en siete semanas.
Cada una es un solo commit ("Oasis release X.Y.Z"), sin historia intermedia: no Cada una es un solo commit ("Oasis release X.Y.Z"), sin historia intermedia: no
hay forma de coger un cambio suelto, siempre llega todo junto. hay forma de coger un cambio suelto, siempre llega todo junto.
- **El backend crece sin parar**: `backend.js` paso de ~9.900 a ~15.400 lineas y se - El backend crece sin parar: `backend.js` paso de ~9.900 a ~15.400 lineas y se
toca en 34 de 39 releases. La cadena de middleware (el array `middleware` del final) toca en 34 de 39 releases. La cadena de middleware (el array `middleware` del final)
ha ganado capas en este tiempo: contexto por peticion (`requestScope`), idioma de ha ganado capas en este tiempo: contexto por peticion (`requestScope`), idioma de
primera ejecucion, CSP, etc. primera ejecucion, CSP, etc.
- **Ya piensa en el movil**: tiene su propio tema `OasisMobile.css`, usa la misma - Ya piensa en el movil: tiene su propio tema `OasisMobile.css`, usa la misma
bandera `process.env.OASIS_MOBILE` que la rama y tiene workflows `activists` y bandera `process.env.OASIS_MOBILE` que la rama y tiene workflows `activists` y
`mobile`. Va en nuestra direccion; cuanto mas nos pisemos con el, peor. `mobile`. Va en nuestra direccion; cuanto mas nos pisemos con el, peor.
- **Las clases CSS cambian, pero poco a poco**: de la 1.0.1 a la 1.2.0 aparecen 335 - Las clases CSS cambian, pero poco a poco: de la 1.0.1 a la 1.2.0 aparecen 335
clases y desaparecen 98; hasta la 1.3.1, +304 / -94; de la 1.3.1 a la 1.3.3, +47 / -8. clases y desaparecen 98; hasta la 1.3.1, +304 / -94; de la 1.3.1 a la 1.3.3, +47 / -8.
Unas 100 clases muertas cada tres semanas, sobre ~2.200: un 5 %. Unas 100 clases muertas cada tres semanas, sobre ~2.200: un 5 %.
@ -64,13 +64,13 @@ cambia el comportamiento de la red, no solo como se ve.
debe seguir). debe seguir).
- `translations/oasis_*.js`: se reescriben en 31 de 39 releases. - `translations/oasis_*.js`: se reescriben en 31 de 39 releases.
- `src/client/assets/styles/style.css` y `mobile.css`: son del dev. - `src/client/assets/styles/style.css` y `mobile.css`: son del dev.
- `src/client/assets/themes/*.css` de upstream, **incluido `OasisMobile.css`**. - `src/client/assets/themes/*.css` de upstream, incluido `OasisMobile.css`.
### Ambar: solo un gancho de una linea, con la bandera de movil ### Ambar: solo un gancho de una linea, con la bandera de movil
Las vistas de upstream (`main_views.js`, `tribes_view.js`, `vote_view.js`, Las vistas de upstream (`main_views.js`, `tribes_view.js`, `vote_view.js`,
`settings_view.js`...). Se reescriben a menudo, asi que lo que la rama necesite ahi va `settings_view.js`...). Se reescriben a menudo, asi que lo que la rama necesite ahi va
como **una llamada a una funcion nuestra**, envuelta en como una llamada a una funcion nuestra, envuelta en
`process.env.OASIS_MOBILE === '1'`, y la logica vive en un fichero propio. Si el dev `process.env.OASIS_MOBILE === '1'`, y la logica vive en un fichero propio. Si el dev
reescribe la vista, se vuelve a poner una linea, no se reconstruye una funcion. reescribe la vista, se vuelve a poner una linea, no se reconstruye una funcion.
@ -93,7 +93,7 @@ reescribe la vista, se vuelve a poner una linea, no se reconstruye una funcion.
| Fichero de upstream | Lineas distintas | Riesgo | | Fichero de upstream | Lineas distintas | Riesgo |
|---|---|---| |---|---|---|
| `themes/OasisMobile.css` | 4.873 | **Alto**: es casi otro fichero. El dev lo toca en 21/39 releases y cada vez hay que elegir entre su version y la nuestra. | | `themes/OasisMobile.css` | 4.873 | Alto: es casi otro fichero. El dev lo toca en 21/39 releases y cada vez hay que elegir entre su version y la nuestra. |
| `views/main_views.js` | 173 | Alto (31/39) | | `views/main_views.js` | 173 | Alto (31/39) |
| `backend/backend.js` | 133 (21 trozos) | Alto (34/39) | | `backend/backend.js` | 133 (21 trozos) | Alto (34/39) |
| `configs/oasis-config.json` | 135 | Medio: es la config de serie del movil | | `configs/oasis-config.json` | 135 | Medio: es la config de serie del movil |
@ -101,7 +101,7 @@ reescribe la vista, se vuelve a poner una linea, no se reconstruye una funcion.
| `backend/updater.js` | 133 | Bajo (3/39) | | `backend/updater.js` | 133 | Bajo (3/39) |
| `views/modules_view.js` | 91 | Bajo (5/39) | | `views/modules_view.js` | 91 | Bajo (5/39) |
| `views/parliament_view.js`, `settings_view.js`, `vote_view.js`, `tribes_view.js` | 50-75 cada una | Medio-alto | | `views/parliament_view.js`, `settings_view.js`, `vote_view.js`, `tribes_view.js` | 50-75 cada una | Medio-alto |
| `models/workflows_model.js` | 31 | Medio: **redefine el workflow `activists` del dev** | | `models/workflows_model.js` | 31 | Medio: redefine el workflow `activists` del dev |
| `server/ssb_config.js`, `SSB_server.js` | 40 | Medio (multicuenta) | | `server/ssb_config.js`, `SSB_server.js` | 40 | Medio (multicuenta) |
Las hojas propias y `OasisMobile.css` llevan selectores a clases que ya no pinta nadie: Las hojas propias y `OasisMobile.css` llevan selectores a clases que ya no pinta nadie:
@ -110,31 +110,31 @@ nada, pero son peso muerto y confunden.
## 4. Reglas para cada cambio ## 4. Reglas para cada cambio
1. **Primero CSS.** Si se arregla con una hoja propia, se arregla ahi. 1. Primero CSS. Si se arregla con una hoja propia, se arregla ahi.
2. **Si hace falta HTML distinto**: funcion en un fichero propio + una linea en la vista 2. Si hace falta HTML distinto: funcion en un fichero propio + una linea en la vista
de upstream, con la bandera de movil. de upstream, con la bandera de movil.
3. **Si hace falta una ruta o retocar una respuesta**: en el router propio. Nunca una 3. Si hace falta una ruta o retocar una respuesta: en el router propio. Nunca una
ruta nueva ni un middleware en `backend.js`. ruta nueva ni un middleware en `backend.js`.
4. **Nunca cambiar lo que se publica ni como se cuenta** (modelos de upstream). 4. Nunca cambiar lo que se publica ni como se cuenta (modelos de upstream).
5. **Textos nuevos** en `i18n_fork.js`, en los 11 idiomas. 5. Textos nuevos en `i18n_fork.js`, en los 11 idiomas.
6. **Nada en linea**: la CSP no deja `style=""` ni `<script>` en la pagina. 6. Nada en linea: la CSP no deja `style=""` ni `<script>` en la pagina.
7. Antes de integrar una release, repetir esta medicion y mirar si alguna clase de la 7. Antes de integrar una release, repetir esta medicion y mirar si alguna clase de la
que dependemos ha desaparecido. que dependemos ha desaparecido.
## 5. Plan para sanear la rama ## 5. Plan para sanear la rama
- **Fase A (hecha el 19/10)**: lo del 19/10 que se metio en ficheros del dev sale a - Fase A (hecha el 19/10): lo del 19/10 que se metio en ficheros del dev sale a
ficheros propios. Ver la seccion 6. ficheros propios. Ver la seccion 6.
- **Fase B: `OasisMobile.css`.** Devolverle la version del dev y llevar nuestra maqueta - Fase B: `OasisMobile.css`. Devolverle la version del dev y llevar nuestra maqueta
a una hoja propia (`styles/mobile_base.css`) que carguen Acampada y el skin a una hoja propia (`styles/mobile_base.css`) que carguen Acampada y el skin
OasisMobile de la rama. Es el mayor foco de conflictos. OasisMobile de la rama. Es el mayor foco de conflictos.
- **Fase C: los 21 trozos antiguos de `backend.js`** (exportar copia de seguridad, - Fase C: los 21 trozos antiguos de `backend.js` (exportar copia de seguridad,
avatar de la topbar, `#t=0.1` en los videos, filtro del lanzador...) pasan al router avatar de la topbar, `#t=0.1` en los videos, filtro del lanzador...) pasan al router
propio como envoltorios. propio como envoltorios.
- **Fase D: workflows.** Devolver `activists` al del dev y registrar los nuestros - Fase D: workflows. Devolver `activists` al del dev y registrar los nuestros
(`acampada`) desde un fichero propio, empujandolos a los arrays que exporta (`acampada`) desde un fichero propio, empujandolos a los arrays que exporta
`workflows_model.js`. `workflows_model.js`.
- **Fase E: limpieza** de selectores muertos en las hojas propias. - Fase E: limpieza de selectores muertos en las hojas propias.
## 6. Fase A: lo que se ha movido ## 6. Fase A: lo que se ha movido