Le but de ce numéro est de fournir un problème global pour suivre l'état du travail nécessaire pour expédier l'édition Octane d'Ember.js.
Si quelqu'un souhaite travailler sur l'un des éléments de cette liste, veuillez d'abord consulter le canal #st-octane de notre chat Discord .
La liste de tâches suivante sera mise à jour pour inclure des liens vers des problèmes individuels au fur et à mesure de leur création. Les numéros eux-mêmes contiendront plus de détails pour chaque élément de cette liste.
Conformément à la feuille de route RFC 2018 , il y a un engagement et une concentration pour terminer les choses que nous avons déjà commencées.
Conformément à la feuille de route RFC, ce sont les objectifs de l'édition Octane ; cependant il faut noter que
"le calendrier final et l'ensemble des fonctionnalités d'Ember Octane seront déterminés par les équipes principales et ne sont pas gravés dans le marbre dans cette RFC."
Champion de l'équipe principale : Tom Dale | Statut : terminé 🎉
Champion de l'équipe principale : Tom Dale | Statut : terminé 🎉
### Propriétés suiviesChampion de l'équipe principale : Tom Dale | Statut : terminé 🎉
### Modificateurs d'élémentsChampion de l'équipe principale : Tom Dale | Statut : terminé 🎉
Champion de l'équipe principale : @tomdale | Statut : en bonne voie ✅
Champion de l'équipe principale : Robert Jackson (@rwjblue) | Statut : terminé 🎉
Champion de l'équipe principale : Robert Jackson | Statut : terminé 🎉
Champion de l'équipe principale : Robert Jackson (@rwjblue) | Statut : en bonne voie ✅
Championne de l'équipe principale : Jen Weber (@jenweber) | Statut : en bonne voie ✅
Championne de l'équipe principale : Leah Silber (@wifelette) & Mel Sumner (@melsumner) | Statut : retardé
Ce sont de nouveaux éléments que nous avons découverts qu'il était nécessaire d'ajouter lors de la mise en œuvre des fonctionnalités d'Octane.
on
modificateurChampion de l'équipe principale : Robert Jackson (@rwjblue) | Statut : terminé 🎉
fn
assistantChampion de l'équipe principale : Robert Jackson (@rwjblue) | Statut : terminé 🎉
Champion de l'équipe principale : Robert Jackson (@rwjblue) | Statut : terminé 🎉
@classic
décorateurChampion de l'équipe principale : Robert Jackson (@rwjblue) | Statut : en bonne voie
Ce sont des éléments qui ont été supprimés d'Octane et qui sont maintenant suivis en tant qu'objectifs étendus.
Des détails
ember-source@3.??.0
ember-data@3.??.0
application-template-wrapper
à false
jquery-integration
à false
template-only-glimmer-components
à true
.ember-cli
ember generate component
à inclure (selon RFC #481) :--no-component-class
--component-structure=flat
EmberObject.extend()
vers des classes natives@MelSumner Nous devrions également suivre les améliorations du pipeline de construction dans https://github.com/embroider-build/embroider .
@melsumner https://broccoli.build et https://github.com/broccolijs/broccolijs.github.io pour le nouveau site et la documentation sur le brocoli
Les propriétés suivies RFC peuvent être cochées et le lien mis à jour.
Nous avons parlé de l'audit de ce qui est inclus dans le plan d'application par défaut. Voir les problèmes connexes :
FWIW, @tomdale qui
ce n'est pas du tout lié à l'octane
Mon raisonnement pour évoquer cela récemment est qu'un plan par défaut qui prend en charge plusieurs modèles de programmation (c'est-à-dire un futur plan d'octane par défaut) peut inclure des éléments supplémentaires dont une application "classique" pure ou une application "octane" pure n'a pas du tout besoin.
Si on peut valider que ce n'est pas un souci, je suis d'accord que ce n'est pas très lié à l'octane
imo, le plan d'octane, https://github.com/ember-cli/ember-octane-blueprint devrait être la toute nouvelle application / brillante _idéale_. Je ne pense pas que l'ancien modèle de programmation devrait être impliqué dans le plan. :-
@MelSumner - Je pense que nous devons obtenir des éléments liés à MU ici dans cette liste de contrôle (je n'en repère aucun, mais AFAICT MU est toujours considéré comme faisant partie de l'ensemble de fonctionnalités d'octane...).
Cela s'appelait déjà disposition Octane au lieu de disposition MU ... et plus j'y pense plus cela a du sens!
@MelSumner - Je pense que nous devons obtenir des éléments liés à MU ici dans cette liste de contrôle (je n'en repère aucun, mais AFAICT MU est toujours considéré comme faisant partie de l'ensemble de fonctionnalités d'octane...).
@rwjblue nous avons lié au problème de la quête MU dans la première section - "Terminer ce que nous avons commencé" - y a-t-il plus que vous pensez que nous devrions suivre ?
Concernant ember-cli-create
j'ai rassemblé ce problème : ember-cli/ember-cli#8343. Selon la quantité de spécifications de broderie qui sera implémentée dans le cadre de l'octane (= format _publication_), le problème que j'ai lié concerne principalement le format _authoring_ qui peut être complémentaire au format de publication.
Personnellement, je ne verrais pas ember-cli-create
comme faisant partie de l'octane alors que le format de création _pourrait_ l'être (ce qui jette les bases de ember-cli-create
).
Faites-moi savoir si cela ferait un bon ajout ou mieux le reporter à la sortie post-octane ou comment je peux aider avec cela.
plan d'octane > déplacer l'addon vers ember-cli org peut être coché :)
Mise à jour, voici un problème de quête pour suivre la conversion des supports d'angle dans les guides https://github.com/ember-learn/guides-source/issues/139
Le Remove jQuery RFC peut être coché ! ??
J'ai également créé un problème de suivi, auquel nous pouvons peut-être créer un lien : https://github.com/emberjs/ember.js/issues/17476
User story autour des indicateurs de fonctionnalité et des fonctionnalités facultatives, en ce qui concerne le plan d'octane
En tant qu'instructeur d'atelier, j'ai besoin de connaître les valeurs par défaut de divers indicateurs facultatifs/de fonctionnalité dans le plan d'octane, afin de comprendre concrètement ce que mes étudiants obtiendront lorsqu'ils exécuteront
ember new
et créeront du matériel autour deember new
qui reste valide sur une période de temps significative.
Pour info - je viens de publier @ember/render-modifiers 1.0.0 avec le support de Ember 2.12 (via ember-modifier-manager-polyfill ). Il y a encore un peu de travail à faire (besoin de beaucoup plus de documentation), mais c'est un bon début...
@MelSumner Je travaillerai sur les plans des classes Native JS.
Quelqu'un a-t-il réfléchi à ce qui devrait se passer pour https://github.com/ember-cli/ember-new-output dans le monde Classic+Octane ?
La sortie de ce référentiel correspondra à la sortie de ember new
, qui, selon nos plans actuels, deviendra le plan d'octane « quand il sera prêt ».
Il semble que l'unification des modules soit absente de la section « Implémentation pratique de la feuille de route RFC ».
Il semble que l'unification des modules soit absente de la section « Implémentation pratique de la feuille de route RFC ».
Je pense que les importations de modèles sont la pièce principale qui n'a pas encore été expédiée, c'est donc la partie que nous suivons dans ce numéro. Est-ce que ça aide, @michaelrkn ?
@MelSumner Compris , merci !
Salut tout le monde, la mise en œuvre de la RFC "Remove jQuery" est en grande partie terminée (au moins en ce qui concerne la première étape Ember 3.x, voir https://github.com/emberjs/ember.js/issues/17476) . Ce qui est toujours ouvert et bloque les plans (par défaut, sans octane) pour passer à aucun jQuery par défaut, c'est la capacité intégrée de ember-data à fonctionner avec fetch
au lieu de $.ajax
(sans devant appliquer le mixin de correctifs ember-data
), voir le PR WIP : https://github.com/emberjs/data/pull/5386.
Juste pour que vous le sachiez... peut-être que cela devrait être abordé lors de l'une des prochaines réunions de l'équipe de base, pour aider à franchir la ligne d'arrivée ?
quelques éléments liés à ember-cli que j'aimerais ajouter à la liste :
moduleConfig.collections = Object.assign(moduleConfig.collections, {
// ember-simple-auth
authenticators: {
types: ['authenticator'],
defaultType: 'authenticator'
}
});
(ce qui précède, avec l'aimable autorisation de @sly7-7 :D )
et
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' },
});
et puis l'autre chose également liée à ember-cli est la prise en charge de plusieurs applications factices.
Jusqu'à présent, nous avons quelques propositions de conception ici :
De plus, je ne sais pas comment suivre cela, mais avec la bibliothèque de papier de braise de @miguelcobain , j'aimerais me coordonner pour rendre le processus de configuration d'octane super simple (actuellement, il n'est pas simple d'utiliser du papier de braise dans les applications d'octane)
Il semble que cela soit principalement dû au fait que les styles sont exposés à l'application hôte. idk s'il y a quelque chose de simple que nous pouvons faire pour que les modules complémentaires de style existants puissent "fonctionner", ou si nous allons faire en sorte que tous les modules complémentaires de style ajoutent une condition d'octane / isModuleUnification ?
@NullVoxPopuli
Salut tout le monde, l'implémentation de la RFC "Remove jQuery" est en grande partie terminée (du moins en ce qui concerne la première étape Ember 3.x, voir #17476). Ce qui est toujours ouvert et bloque les plans (par défaut, sans octane) pour passer à aucun jQuery par défaut, c'est la capacité intégrée de ember-data à fonctionner avec
fetch
au lieu de$.ajax
(sans devant appliquer leember-data
patch mixin) , voir le WIP PR : emberjs/data#5386 .Juste pour que vous le sachiez... peut-être que cela devrait être abordé lors de l'une des prochaines réunions de l'équipe de base, pour aider à franchir la ligne d'arrivée ?
@dgeb / @igorT pouvez-vous aider avec ce bloqueur ?
@MelSumner Oui , https://github.com/emberjs/data/pull/5386
@MelSumner
Update blueprints for each object type to use native JS classes
a été fusionné à #17621. Initialement, les blueprints généreront des classes natives uniquement lors de l'utilisation des blueprints d'octane .
@tomdale , @MelSumner , @rwjblue
https://github.com/crashco/ember-template-component-import/issues/10
Pour info, le RFC sur les modèles de composants co-locations n'est pas encore sur ce problème de suivi. :)
@ Panman8201 correct - c'est en dehors de la portée d'Octane. :)
Je pense que cela doit être mis à jour avec la version Ember Octane 3.15+ :)
Depuis que nous avons expédié Octane, je vais clore ce problème.
Commentaire le plus utile
@melsumner https://broccoli.build et https://github.com/broccolijs/broccolijs.github.io pour le nouveau site et la documentation sur le brocoli