profile
viewpoint
Sergey Astapov SergeAstapov Kharkiv, Ukraine

fivetanley/ember-cli-dotenv 189

Dotenv for your ember app through ember-cli

johno/broccoli-csslint 4

Add CSS linting to your Broccoli tree.

SergeAstapov/ember-cli-jsdoc 1

An Ember CLI addon to generate HTML documentation from JSDoc comments in the source code.

SergeAstapov/broccoli-stylus-single 0

Broccoli plugin for compiling Stylus files to CSS with n-to-one semantics

SergeAstapov/data 0

A data persistence library for Ember.js.

SergeAstapov/ember-a11y-testing 0

A suite of accessibility tests that can be run within the Ember testing framework

SergeAstapov/ember-animated 0

Core animation primitives for Ember.

SergeAstapov/ember-app-scheduler 0

An Ember addon to schedule work until after the initial render.

SergeAstapov/ember-blog 0

Ember's official blog

issue commentemberjs/rfcs

Feature Request: consistent API between classic and Glimmer components

If talks about use cases, for example, I have wrote an addon with itemscontrol (like in wpf), where component (item container) should be created in code, in response to itemcollection changing. Now I have to create model of component and render it in template. I would like to create and initialize component in code and manage component lifecycle by myself.

boris-petrov

comment created time in 20 hours

issue commentemberjs/rfcs

Component helper in JS

If talks about use cases, for example, I have wrote an addon with itemscontrol (like in wpf), where component should be created in code, in response to itemcollection changing. Now I have to create model of component and render it in template. I would like to create and initialize component in code and manage component lifecycle by myself.

mehulkar

comment created time in 20 hours

Pull request review commentkategengler/ember-cli-code-coverage

ember-cli-update to Ember 3.22 blueprint

 module.exports = {   env: {     browser: true,   },-  rules: {-    'ember/no-jquery': 'error',

why did you remove this rule?

loganrosen

comment created time in a day

Pull request review commentkategengler/ember-cli-code-coverage

ember-cli-update to Ember 3.22 blueprint

 module.exports = async function () {   return {     scenarios: [       {-        name: 'ember-lts-3.12',+        name: 'ember-lts-3.16',

why are you dropping support for Ember 3.12?

loganrosen

comment created time in a day

Pull request review commentkategengler/ember-cli-code-coverage

ember-cli-update to Ember 3.22 blueprint

 module.exports = async function () {           },         },       },-      // The default `.travis.yml` runs this scenario via `npm test`,-      // not via `ember try`. It's still included here so that running-      // `ember try:each` manually or from a customized CI config will run it-      // along with all the other scenarios.-      {-        name: 'ember-default',-        npm: {-          devDependencies: {},-        },-      },

why are you removing this scenario?

loganrosen

comment created time in a day

pull request commentember-fastboot/fastboot-app-server

Add `app` option to express-http-server

@rwjblue will do (eventually, because the app I'm working on right now is not FastBoot-enabled)

zeppelin

comment created time in 2 days

push eventemberjs/core-notes

Ricardo Mendes

commit sha dbd2cb2f186a95fd68537440b9a18e050c4bbc78

Update 2020-12-03.md

view details

push time in 2 days

PR opened emberjs/core-notes

Learning december 03
+54 -0

0 comment

1 changed file

pr created time in 2 days

create barnchemberjs/core-notes

branch : learning-december-03

created branch time in 2 days

create barnchemberjs/core-notes

branch : learning-november-26

created branch time in 2 days

issue closedemberjs/rfcs

Deprecate the usage of Ember.on for Component's lifecycle events.

Request

Deprecate this:

Ember.Component.extend({
  someRandomName: Ember.on('didInsertElement', function() {
  })
});

In favor of:

Ember.Component.extend({
  didInsertElement: function() {
    this._super(...arguments);
  }
});

Reasoning

Ember.Component.extend({
  doA: Ember.on('willInsertElement', function() { },
  doB: Ember.on('willInsertElement', function() { }
})

The order in which doA and doB happens is unknown. This code might be the result of a refactoring. Or, a developer new to the code base not noticing that the event is being observed already. Subtle bugs can be easily introduced.

It is also easier to read and understand the behavior of a component if there is a single place where all the event dependent code is executed. Tracking down all the different pieces of code that are executed at different moments in the lifecycle is cumbersome and can be easily avoided by using overrides.

One argument that might come up against overrides is:

what if people forgets to call super? that can introduce bugs too!

It is easier to know that you always have to have that call inside the hook, there is determinism. Whereas keeping track of all the Ember.ons that might be cohabiting an object is not straightforward. When reading the code, you have to keep a mental map of all the pieces that might be executed by a hook; the cognitive load is high.

closed time in 3 days

givanse

issue commentemberjs/rfcs

Deprecate the usage of Ember.on for Component's lifecycle events.

Very happy to close! Thanks.

givanse

comment created time in 3 days

issue commentemberjs/rfcs

Deprecate the usage of Ember.on for Component's lifecycle events.

Thanks everyone for the discussion! @givanse what do you feel about closing this issue given that Glimmer components are now the default implementation and they do not have lifecycle hooks?

givanse

comment created time in 3 days

issue commentemberjs/rfcs

Colocate route+template+controllers

After investigating ember-strict-resolver a bit, I think both of the options (exporting Controller from the route file, or having a dedicated my-page.controller.js file) would be doable with the resolver.

I tried to setup https://github.com/stefanpenner/ember-strict-resolver in our app to use these rules. The main problem was that there was a build error when having files like these:

  • app/routes/debug.js
  • app/routes/debug.hbs
Build Error (TemplateCompiler)

EEXIST: file already exists, symlink '/my-app/app/routes/debug.js' -> 
'/tmp/broccoli-96329Dq3bCOsDcC1e/out-433-template_compiler/my-app/routes/debug.js'

I guess this requires a change in ember-cli-htmlbars to handle this similar to component template colocation.

For experimentation, I made it work with a structure like this:

  • app/routes/debug.js
  • app/routes/debug-template.hbs

Which worked reasonably well. I could detect the presence of a Controller export just fine.

The main downside, from an ergonomics perspective, I could find was that you end up with something like this:

class ApplicationController extends Controller {
  // stuff goes in here
}

export { ApplicationController as Controller };

Which is not super smooth, but OK I guess. It also does feel a bit "magic" - more magic than having e.g. app/routes/debug.controller.js, imho. I would be fine with either solution though, personally.

For reference, the key part was something like this:

class CustomResolver extends EmberStrictResolver {
  hasController(moduleName: string) {
    return this.has(moduleName) && Boolean(require(moduleName)?.Controller);
  }

  _getModuleNameForController(
    fullName: string,
    { prefix, name }: ModuleDefinition
  ) {
    // try colocation...
    let moduleName = `${prefix}/routes/${name}`;
    if (this.hasController(moduleName)) {
      return { moduleName, export: 'Controller' };
    }

    // try index
    moduleName = `${prefix}/routes/${name}/index`;
    if (this.hasController(moduleName)) {
      return { moduleName, export: 'Controller' };
    }

    // try pod
    moduleName = `${prefix}/${name}/controller`;
    if (this.has(moduleName)) {
      return { moduleName, export: 'default' };
    }

    // fall back to default
    return super.moduleNameForFullName(fullName);
  }
}
mehulkar

comment created time in 3 days

pull request commentemberjs/rfcs

Deprecate Fallback Lookup Paths in ember-resolver

The main issues I encountered were:

  • Missing pod support (as mentioned)
  • Missing support for nested co-location index components (e.g. app/components/my-component/index.js)
  • Missing pluralization support. Noticed this with ember-can, which has e.g. app/abilitites/my-thing.js, but it wants to look up ability as abilitys. IMHO there should either be support for custom pluralization, or alternatively just do not pluralize unkown types at all - I would be fine with putting these into app/ability/my-thing.js.
  • After I got nested co-location to work, components from addons using non-colocated structure stopped working for me. Had to manually handle those.
  • That I had to manually map all multi-word services was also rather unexpected and annoying.

For reference, here is the extended strict resolver that ended up working with our application. There is for sure some room for improvement, but it shows the steps I took to make it work at least: https://gist.github.com/mydea/d890f3b83a4bf25b3c3a4f41f6a47e42

gabrielcsapo

comment created time in 3 days

issue commentemberjs/rfcs

Thoughts on deprecating prototype extensions?

Could we add ember-disable-prototype-extensions to the app blueprint in a minor release of ember-cli? Would that help the effort?

NullVoxPopuli

comment created time in 4 days

issue commentemberjs/rfcs

Thoughts on deprecating prototype extensions?

You basically answered yourself 😁 What flips the default values for the optional features is the presence of the of the ember.edition key in package.json. If you have a pre-Octane app and upgrade the ember-source version alone to 3.15+ and don't touch anything else, your app will continue working as intended.

NullVoxPopuli

comment created time in 4 days

issue commentemberjs/rfcs

Thoughts on deprecating prototype extensions?

I don't understand:

it would be a breaking change to disable the extensions by default

we, in 3.x's default blueprint:

  • disabled the the application-template-wrapper
  • enabled glimmer template only components
  • turned off jquery integration
  • and switched to async observers
  • changed all the generated blueprints based on a flag in package.json

those were all by behind optional features, and changed as part of an edition.

by "breaking change" do you mean, "would require edition-level efforts to introduce in the 3.x timeline?

NullVoxPopuli

comment created time in 4 days

issue commentemberjs/rfcs

Thoughts on deprecating prototype extensions?

I looked into the state of these prototype extensions to provide some more context. Keep in mind that this is for the application blueprint, since the addon blueprint has disabled prototype extensions for quite some time. According to the source code, the existing extensions match the documentation, String, Function, and Array.

  1. Function

These have been deprecated and can be disabled by default for 4.0

  1. String

These also have recently been deprecated (available as of 3.24.0-beta.1). These prototype extensions could be disabled by default for 4.0 if the deprecation is released (enabled) at the correct time.

  1. Array

This one is trickier. There is some discussion in the Array functions RFC. As mentioned in a comment in the thread, I believe Ember Data makes use of these APIs (I'm confirming), so as long as that is true and Ember Data is included in the default blueprint, it would be a breaking change to disable the extensions by default.

I think the work then is to advance the deprecation of the Array prototype extensions so they can be removed at a later major version.

NullVoxPopuli

comment created time in 4 days

pull request commentemberjs/rfcs

Deprecate Fallback Lookup Paths in ember-resolver

@mydea thanks for your repy!

  1. Totally agree there needs to be a pods replacement, the suggestion for moving forward makes this opt in and since the usage of pods seems constrained to host applications they wouldn't be affected. A suggestion came up when talking to @rwjblue was to have a shim fo pods instead of having that in the main resolver.
  2. We had a similar experience, most of the issues came from our dependencies and our host app not having a consistent service or component lookup pattern. I would like to know what problems you experienced if you could do a writeup that would be great.
gabrielcsapo

comment created time in 4 days

pull request commentebryn/ember-component-css

Support colocated components

@webark where are we on this?

imagolive

comment created time in 4 days

issue openedemberjs/rfcs

Thoughts on deprecating prototype extensions?

Having primarily worked in addons for some time now, I'm surprised that prototype extensions are still default in apps.

https://guides.emberjs.com/v3.22.0/configuring-ember/disabling-prototype-extensions/

right at the top it says:

By default, Ember.js will extend the prototypes of native JavaScript objects in the following ways:

I'd like to have no native prototype touched by any Library / Framework -- it makes me think of the 2012 times, ya know?

What are people's thoughts on a to-be-written RFC to deprecate prototype extensions / making them an "Optional feature"?

created time in 4 days

PR closed emberjs/rfcs

Better environment handling T-Tooling T-testing
+137 -0

19 comments

1 changed file

mydea

pr closed time in 4 days

pull request commentemberjs/rfcs

Better environment handling

I think we can close this, as this can be pretty nicely accomplished now using @embroider/macros:

import { isTesting, isDevelopingApp } from '@embroider/macros';

Works like a charm in our app, and can properly tree-shake code when used with macroCondition :+1:

mydea

comment created time in 4 days

pull request commentemberjs/rfcs

Deprecate Fallback Lookup Paths in ember-resolver

I generally think this is a good idea, my two cents to this:

  • I believe a replacement for pods needs to be defined before doing that. We use pods for route/controller/templates, and would not like to move those to the classic architecture. See: https://github.com/emberjs/rfcs/issues/651 - would love to see some traction on that. If there is interest, I would also write up an RFC PR for that issue based on the ideas collected so far in the issue - it kind of quieted down and there was never any input from the core team on how they view the issue.
  • I have tried the mentioned ember-strict-resolver and found a lot of problems with it in our app. Not sure if the idea of this RFC is to use that as basis, but if so, I think there is a lot that needs to be done on that front before it could be recommended. Happy to write up my concrete experiences, if that helps in the context of this PR?
gabrielcsapo

comment created time in 4 days

PR opened emberjs/rfcs

Deprecate Fallback Lookup Paths in ember-resolver

This is a follow up rfc created based on the feedback from issue #661.

+137 -0

0 comment

1 changed file

pr created time in 5 days

pull request commentemberjs/rfcs

Deprecate Implicit Injection on arbitrary Ember Framework objects

One use case I have that does not seem easy to migrate is to inject a service that registers global route events to route:application in an initializer. This will eagerly instrument all route transitions without lookup the service in an instance-initializer, otherwise, I cannot mock the service in the test setup.

snewcomer

comment created time in 5 days

Pull request review commentemberjs/rfcs

Deprecate Implicit Injection on arbitrary Ember Framework objects

+- Start Date: 2020-10-04+- Relevant Team(s): Ember.js+- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name)+- Tracking: (leave this empty)++# Implicit Injection Deprecation++## Summary++This RFC seeks to deprecate implicit injections on arbitrary Ember Framework objects. This is commonly done via `owner.inject` in an+intializer or instance-initializer.++A prevalent example of implicit injection is found in `ember-data` [injecting](https://github.com/emberjs/data/blob/4bd2b327c4cbca831f9e9f8bc6b497200a212f9b/packages/-ember-data/addon/setup-container.js) their default `store` into all+Ember.Route and Ember.Controller factory objects. Here is a pruned example of how this looks.++```js+// app/initializers/store-inject.js+export function initialize(application) {+    application.inject('route', 'store', 'service:store');+    application.inject('controller', 'store', 'service:store');+}++export default {+    name: 'store-inject',+    initialize,+};+```++```js+export default class PostRoute extends Route {+  // This proposal seeks to make this service injection explicit+  // Currently users do no need to specify this injection if ember-data is installed+  // @service store;++  model() {+    return this.store.findRecord('post', 1);+  }+}+```++Ensuring a property is present on Ember's Framework objects should be explicitly defined. This will allow the Ember ecosystem to+further progress the framework while easing the learning curve for all developers.++## Motivation++Implicit injections have long confused developers onboarding Ember projects. Without an+explicit injection visible on the class body, developers start to wonder how certain properties got there.+We can infer from a common implicit injection in `ember-data` to reason about some of the downsides this presents.+If a project has `ember-data` installed, an initializer at runtime registers the `@ember-data/store` on both+Ember.Route and Ember.Controller factory objects.  This is a nice convenience for a project with many routes+that are used for data fetching. However, it leads to many inconveniences that hinder learning and advancement+of the framework. This includes:++1. By entangling specific objects with the whole dependency tree, we might be preventing incremental adoption.+   For example, `ember-data` has laid out its plan for adopting only specific packages in [Project Trim](https://github.com/emberjs/data/issues/6166).+   However, because `store` is injected by default on all Ember.Route and Ember.Controller factory objects,+   a user cannot easily opt out of `@ember-data/store`. This is a common problem space in other communities as well.+   With previous JetBrains IDE installations, adding plugins required a reload. However, by removing a contructor function+   that injected all the dependencies at once, they were able to avoid reload after installation of a plugin.++2. Eager initialization of the dependency tree from which the property came from prevents tree shaking and incurs a+   performance hit. For example, if you app does not need `ember-data` to render the entry route, the `store` injection will+   take up more CPU cycles than necessary, hurting common user facing metrics.++3. Eager initialization makes it hard to users to write tests that need to take advantage of a stub.+   This is often a silent and annoying hurdle that users have to get around when writing tests.+   Moreover, this is especially apparent for users moving to Ember's new testing APIs in [RFC 232](https://github.com/emberjs/rfcs/blob/master/text/0232-simplify-qunit-testing-api.md) and [RFC 268](https://github.com/emberjs/rfcs/blob/master/text/0268-acceptance-testing-refactor.md),+   ensuring instance initializers run before each test.++4. Injection on commonly used framework objects can lead to deviation of project specific styleguides. For instance,+   injecting the `router` on the Ember.Component factory object will certainly lead to instances where the `router` is explicitly+   injected and other instances where is it implicitly injected.++5. Users have come to associate `Route.model()` with a hook that returns `ember-data` models in the absense of explicit injection.+   While this can be true, it is not wholly true. New patterns of data loading are becoming+   accepted in the community including opting to fetch data in a Component.+++## Detailed design++Removing implicit injections is not possible until we first issue deprecations.+This helps us maintain our strict semver commitment to not completing a major version bump and+removing APIs without a deprecation path. As a result, it will take us 3 phases to remove `owner.inject`.++### 1. Deprecate implicit injection on target object++The first step will be issuing a deprecation on the target factory object that is receiving a property. This will surface the deprecation+on user's owned objects including transitively through addons like `ember-data`. This can be accomplished by installing a native getter+and setter on the target. Whenever the property is accessed, we will check if the property is explicitly injected. If it isn't,+we will issue a deprecation with an until value, id and url to read more about this deprecation.++### 2. Deprecate `owner.inject`++The first phase did not actually deprecate the "use" of `owner.inject`.  As a result, we need to deprecate+it's use directly before removing.++### 3. Profit!++Ember 4.0 will remove the ability to utilize `owner.inject` to inject arbitrary properties on Ember's Framework objects.++It is important to consider the timeline of these three phases.  Many addons and apps will need to make minor and major+changes to their codebase. We need to consider this as we move through each phase.

As for the triggers, how does this sound?

  1. Introduce deprecation on target
  2. Next release introduce deprecation on owner.inject
  3. Simmer until v4?
snewcomer

comment created time in 6 days

pull request commentemberjs/rfcs

Adding Logical Operators to Templates

Any updates on this? Given that the need for these helpers is quite ubiquitous I believe and trivial to implement (except for the short-circuiting maybe), advancing this RFC seems like a very low-hanging fruit to me!

I would like to add one thing though: has another helper like {{default}} been considered? It might not be truly a "truth helper", but {{or}} is also not really used as a boolean logic operator in most cases, but rather as a way to provide a default value, as in @cibernox's previous example:

<img class="avatar" src={{or @user.avatar "/imgs/default-avatar.png"}}>

Tbh, I don't like this pattern that much, because

  • it does not clearly express the intent, as this is not about some boolean operation that returns a boolean. Rather it relies on JavaScript's loosely typed interpretation of boolean logic, which in this case would return the second argument if the first evaluates to falsy
  • given that loosely typed behavior, this happens to work for string values as in the example above, but fails miserably for other values that should be considered valid values (i.e. which should not get overridden by the default value) but evaluate to falsy (false, 0, ""). Take this example:
<Modal @open={{or @modalOpen true}}/>

(The modal would always be open here, no matter what you pass as @modalOpen)

That's why I am so happy about the nullish coalescing (??) operator that we have now in JS-land, as it handles both these concerns (intent and behavior) much better than ||.

Side node: you see I am not a fan of JavaScript's loose interpretation of boolean logic in general. Maybe because of the stronger mathematical education I enjoyed in school and university. I just find that boolean logic is soo easy to reason about when constrained to functions that take one or more booleans and return a boolean (truth tables!). As it was supposed to be! But JS semantics are obviously not going to change. So here we go, and sorry for my slightly off-topic rant here! 😆

So basically I would propose to add something like {{default}} (we can argue about naming of course), which is basically implemented using ??, just as {{or}} would basically use || (except for the slightly different handlebars semantics of truthiness).

You could argue that this can be added in its own RFC, however I would argue that once you add {{or}} to Ember's core, it would perpetuate that use (IMHO misuse), and it would be hard to roll it back later.

cibernox

comment created time in 6 days

more