El propósito de este problema es proporcionar un problema general para rastrear el estado del trabajo necesario para enviar Octane Edition de Ember.js.
Si alguien quiere trabajar en alguno de los elementos de esta lista, primero verifique en el canal # st-octane de nuestro chat de Discord .
La siguiente lista de tareas pendientes se actualizará para incluir enlaces a problemas individuales a medida que se crean. Los problemas en sí mismos contendrán más detalles para cada elemento de esta lista.
Según el RFC de la hoja de ruta de 2018 , existe un compromiso y un enfoque para terminar las cosas que ya comenzamos.
Según la hoja de ruta RFC, estos son los objetivos de la edición Octane; sin embargo, debe tenerse en cuenta que
"La línea de tiempo final y el conjunto de características de Ember Octane serán determinados por los equipos centrales y no están escritos en piedra en este RFC".
Campeón del equipo principal: Tom Dale | Estado: completado 🎉
Campeón del equipo principal: Tom Dale | Estado: completado 🎉
### Propiedades rastreadasCampeón del equipo principal: Tom Dale | Estado: completado 🎉
### Modificadores de elementosCampeón del equipo principal: Tom Dale | Estado: completado 🎉
Campeón del equipo principal: @tomdale | Estado: en pista ✅
Campeón del equipo principal: Robert Jackson (@rwjblue) | Estado: completado 🎉
Campeón del equipo principal: Robert Jackson | Estado: completado 🎉
Campeón del equipo principal: Robert Jackson (@rwjblue) | Estado: en pista ✅
Campeona del equipo principal: Jen Weber (@jenweber) | Estado: en pista ✅
Campeona del equipo principal: Leah Silber (@wifelette) y Mel Sumner (@melsumner) | Estado: retrasado
Estos son elementos nuevos que descubrimos que era necesario agregar al implementar las funciones de Octane.
on
modificadorCampeón del equipo principal: Robert Jackson (@rwjblue) | Estado: completado 🎉
fn
ayudanteCampeón del equipo principal: Robert Jackson (@rwjblue) | Estado: completado 🎉
Campeón del equipo principal: Robert Jackson (@rwjblue) | Estado: completado 🎉
@classic
decoradorCampeón del equipo principal: Robert Jackson (@rwjblue) | Estado: en camino
Estos son elementos que se quitaron del alcance de Octane y ahora se registran como objetivos exagerados.
Detalles
ember-source@3.??.0
ember-data@3.??.0
application-template-wrapper
a false
jquery-integration
a false
template-only-glimmer-components
a true
.ember-cli
ember generate component
para incluir (por RFC # 481) :--no-component-class
--component-structure=flat
EmberObject.extend()
a clases nativas@MelSumner También deberíamos realizar un seguimiento de las mejoras de la canalización de compilación en https://github.com/embroider-build/embroider .
@melsumner https://broccoli.build y https://github.com/broccolijs/broccolijs.github.io para el nuevo sitio y documentos de brócoli
Las propiedades rastreadas RFC se pueden marcar y actualizar el enlace.
Hablamos sobre la auditoría de lo que se incluye en el plan de aplicación predeterminado. Ver problemas relacionados:
Fwiw, @tomdale que parece bastante ortogonal a la edición del octano para mí (no diciendo que no debemos tener más cuidado y tienen mejores cheques / saldos, sólo que no está relacionado con su octanaje en absoluto) ...
no está relacionado con el octano en absoluto
Mi razonamiento para mencionar esto recientemente es que un plan predeterminado que admita múltiples modelos de programación (es decir, un plan futuro de octanaje predeterminado) puede incluir un elemento adicional que una aplicación "clásica" pura o una aplicación de "octanaje" puro no necesita en absoluto.
Si podemos validar que esto no es una preocupación, estoy de acuerdo en que esto no está muy relacionado con el octanaje.
En mi opinión, el plano del octano, https://github.com/ember-cli/ember-octane-blueprint debería ser la aplicación nueva / brillante _ideal_. No creo que el antiguo modelo de programación deba estar involucrado en el plan. : -
@MelSumner : creo que necesitamos obtener algunas cosas relacionadas con MU aquí en esta lista de verificación (no veo ninguna, pero AFAICT MU todavía se considera parte del conjunto de características de octanaje ...).
Ya se ha llamado diseño de Octane en lugar de diseño de MU ... ¡y cuanto más lo pienso, más tiene sentido!
@MelSumner : creo que necesitamos obtener algunas cosas relacionadas con MU aquí en esta lista de verificación (no veo ninguna, pero AFAICT MU todavía se considera parte del conjunto de características de octanaje ...).
@rwjblue vinculamos al problema de la misión MU en la primera sección, "Terminamos lo que comenzamos". ¿Hay más
Con respecto a ember-cli-create
, armé este problema: ember-cli / ember-cli # 8343. Dependiendo de la cantidad de especificaciones de bordado que se implementen como parte del octano (= _ formato de publicación_), el problema que vinculé se refiere principalmente al formato de _autorización_, que puede ser complementario al formato de publicación.
Personalmente, no vería ember-cli-create
como parte de octano mientras que el formato de autoría _podría_ ser (que básicamente establece las bases para ember-cli-create
).
Avíseme, si eso sería una buena adición o mejor posponerlo para el lanzamiento posterior al octanaje o cómo puedo ayudar con eso.
plan de octano> mover complemento a ember-cli org se puede marcar :)
Actualización, aquí hay un problema de búsqueda para rastrear la conversión de corchetes angulares en las guías https://github.com/ember-learn/guides-source/issues/139
¡Se puede marcar la opción Eliminar jQuery RFC! ✅
También creé un problema de seguimiento, al que podemos vincular tal vez: https://github.com/emberjs/ember.js/issues/17476
Historia de usuario en torno a banderas de funciones y funciones opcionales, en lo que respecta al modelo de octanaje
Como instructor de taller, necesito conocer los valores predeterminados para varios indicadores opcionales / de características en el plan de octanaje, para comprender de manera concreta lo que obtendrán mis estudiantes cuando ejecuten
ember new
, y construyan material alrededor deember new
que sigue siendo válido durante un período de tiempo significativo.
Para su información: acabo de publicar @ ember / render-modifiers 1.0.0 con soporte para Ember 2.12 (a través de ember-modifier-manager-polyfill ). Todavía hay un poco de trabajo por hacer (se necesita mucha más documentación), pero es un buen comienzo ...
@MelSumner Trabajaré en los planos de Native JS Classes.
¿Alguien ha pensado en lo que debería suceder para https://github.com/ember-cli/ember-new-output en el mundo Classic + Octane?
La salida en ese repositorio coincidirá con la salida de ember new
, que de acuerdo con nuestros planes actuales cambiará al modelo de octanaje "cuando esté listo".
Parece que falta la unificación de módulos en la sección "Implementación práctica de la hoja de ruta RFC".
Parece que falta la unificación de módulos en la sección "Implementación práctica de la hoja de ruta RFC".
Creo que las importaciones de plantillas son la pieza principal que aún no se ha enviado, por lo que esa es la parte que estamos rastreando en este problema. ¿ Eso ayuda,
@MelSumner ¡Entendido , gracias!
Hola a todos, la implementación de la RFC "Eliminar jQuery" se realiza en su mayoría (al menos en lo que respecta a la primera etapa Ember 3.x, consulte https://github.com/emberjs/ember.js/issues/17476) . Lo que todavía está abierto y bloquea los planos (predeterminados, sin octanaje) para cambiar a no jQuery de manera predeterminada es la capacidad incorporada de ember-data para trabajar con fetch
lugar de $.ajax
(sin tener que aplicar la mezcla de parches ember-data
), consulte WIP PR: https://github.com/emberjs/data/pull/5386.
Solo para hacerle saber ... ¿tal vez esto debería abordarse en una de las próximas reuniones del equipo central, para ayudar a llevar esto a la meta?
un par de cosas relacionadas con ember-cli que me gustaría agregar a la lista:
moduleConfig.collections = Object.assign(moduleConfig.collections, {
// ember-simple-auth
authenticators: {
types: ['authenticator'],
defaultType: 'authenticator'
}
});
(lo anterior, cortesía de @ sly7-7: D)
y
moduleConfig.types = Object.assign(moduleConfig.types, {
// ember-intl
'ember-intl<strong i="12">@adapter</strong>': { definitiveCollection: 'main' },
'ember-intl<strong i="13">@translation</strong>': { definitiveCollection: 'main' },
translation: { definitiveCollection: 'main' },
formats: { definitiveCollection: 'main' },
cldr: { definitiveCollection: 'main' },
'util:intl': { definitiveCollection: 'utils' },
'intl:util': { definitiveCollection: 'utils' },
// ember-gestures
'ember-gesture': { definitiveCollection: 'main' },
});
y luego, la otra cosa también relacionada con ember-cli es que admite múltiples aplicaciones ficticias.
Hasta ahora tenemos aquí algunas propuestas de diseño:
Además, no estoy seguro de cómo rastrear esto, pero con la biblioteca de papel de ascua de @miguelcobain , me gustaría coordinarme para que el proceso de configuración de octano sea súper simple (actualmente no es simple usar papel de ascuas en aplicaciones de octano)
Parece que tiene que ver principalmente con que los estilos se exponen a la aplicación de host. idk si hay algo simple que podamos hacer para que los complementos de estilo existentes puedan "simplemente funcionar", o si vamos a hacer que todos los complementos de estilo agreguen una condición octanaje / isModuleUnification?
@NullVoxPopuli
Hola a todos, la implementación de la RFC "Eliminar jQuery" se ha realizado en su mayor parte (al menos en lo que respecta a la primera etapa Ember 3.x, ver # 17476). Lo que todavía está abierto y bloquea los planos (predeterminados, sin octanaje) para cambiar a no jQuery de manera predeterminada es la capacidad incorporada de ember-data para trabajar con
fetch
lugar de$.ajax
(sin tener que aplicar la mezcla de parcheember-data
) , consulte el WIP PR: emberjs / data # 5386 .Solo para hacerle saber ... ¿tal vez esto debería abordarse en una de las próximas reuniones del equipo central, para ayudar a llevar esto a la meta?
@dgeb / @igorT ¿puedes ayudar con este bloqueador?
@MelSumner Sí, https://github.com/emberjs/data/pull/5386
@MelSumner
Update blueprints for each object type to use native JS classes
se ha fusionado en # 17621. Inicialmente, los planos generarán clases nativas solo cuando se utilicen los planos de octanaje .
@tomdale , @MelSumner , @rwjblue
https://github.com/crashco/ember-template-component-import/issues/10
Para su información, el RFC de ubicaciones conjuntas de plantillas de componentes aún no se ocupa de este problema de seguimiento. :)
@ Panman8201 correcto: está fuera del alcance de Octane. :)
Creo que es necesario actualizarlo con la versión Ember Octane 3.15+ :)
Desde que enviamos Octane, vamos a cerrar este problema.
Comentario más útil
@melsumner https://broccoli.build y https://github.com/broccolijs/broccolijs.github.io para el nuevo sitio y documentos de brócoli