@bartocc wrote:

While migrating a 3.1.4 project to 3.2, I ran into the following error:

Class constructor A cannot be invoked without 'new'.

The project has 2 models, A and B, defined with ES6 class/extends syntax thanks to ember-decorators.

// models/a.js
import DS from 'ember-data';

export default class A extends DS.Model {
}

// models/b.js
import A from './a';

// I need A.extend() here for polymorphic relationship reasons
export default class B extends A.extend() {
}

This code works under 3.1.4 but fails under 3.2 and I do not understand why.

The workaround I’ve found is to define A with EmberObject.extend() instead of using ES6 class syntax.

// models/a.js
import DS from 'ember-data';

// this works under 3.1 and 3.2
export default DS.Model.extend({});

Another way to fix the issue is to define B like this

// models/b.js
import A from './a';

// no more A.extend(), so no more bug, but it does not fit my needs.
export default class B extends A {
}

I’ve setup a repo to reproduce the bug:

I’d love to understand what’s going on here and how I could migrate to 3.2 without refactoring A to use EmberObject.extend

Posts: 1

Participants: 1

Read full topic

@melriffe wrote:

I have a model that, for business reasons, has an attribute that contains a value from a global counter. This attribute needs to be displayed.

Oh, some background: Ember 2.18 + Rails 5.2 API back-end w/jsonapi-resources gem. On the Rails side said Resource has this attribute removed from the list of createable & updateable fields lists.

The backend is configured to not expect it in the attributes hash when creating or updating said model.

Is there a way to exclude this attribute when saving/updating the model?

Thank you for your time.

Posts: 1

Participants: 1

Read full topic

@bartocc wrote:

Let’s create an app with 3 models, User, Post and SpecialPost. They are all defined with the ES6 class/extends syntax thanks to ember-decorators.

// models/user.js
import DS from 'ember-data';
import { hasMany } from '@ember-decorators/data';
const { Model } = DS;

export default class UserModel extends Model {
  @hasMany() posts;
}

// models/post.js
import DS from 'ember-data';
const { Model } = DS;

export default class PostModel extends Model {}

// models/special-post.js
import Post from './post';

export default class SpecialPostModel extends Post {}

When trying to assign a special-post to a user, I get an error:

    const post = this.store.createRecord('special-post');
    return this.store.createRecord('user', {posts: [post]});
// =>  Assertion Failed: You cannot add a record of modelClass 'special-post' to the 'user.posts' relationship (only 'post' allowed)

Since SpecialPost is a subclass of Post, I thought this would automatically work…

One workaround I’ve found is to declare SpecialPost this way:

// models/special-post.js
import Post from './post';

// note the Post.extend() part
export default class SpecialPostModel extends Post.extend() {}

Unfortunately, this works under Ember 3.1 but does not under 3.2 (see Ember 3.2 + ember-decorators subclassing bug)

Here is a repo reproducing the bug:

How can I assign a special-post to a user only using ES6 class syntax without the extends Post.extend() hack?

Posts: 1

Participants: 1

Read full topic

@tomdale wrote:

I wanted to make something very clear, in response to @mfeckie’s Are we (still) a welcoming community? thread.

In the Ember community, dissent is not just tolerated, it is encouraged. We will fail if people believe they have to stay silent when they disagree with the core team or community consensus.

I want to quote from one of my blog posts, all the way back in 2013:

Developer communities have a habit of crafting mantras that they can repeat over and over again. These distill down the many nuances of decision-making into a single rule, repeated over and over again, that the majority of people can follow and do approximately the right thing. This is good.

However, the downside of a mantra is that the original context around why it was created gets lost. They tend to take on a sort of religious feel. I’ve seen in-depth technical discussions get derailed because people would invoke the mantra as an axiom rather than as having being derived from first principles…

Mantras are useful for aligning a developer community around a set of norms, but they don’t take into account that the underlying assumptions behind them change. They tend to live on a little bit beyond their welcome.

The topic at the time was “progressive enhancement.” Ember has been around long enough now that we’ve since developed our own mantras. We need to make sure that the ease of falling back on those mantras doesn’t cause us to lose sight of the bigger picture. When we engage with other community members, particularly those who are new, we need to ensure that we’re understanding and validating their unique circumstances, not shutting them down with terse dogma.

Ember is also a big tent. Even though each new app comes with the same set of defaults, it’s unrealistic to believe those defaults are right for every situation.

To quote from the Rails doctrine:

As with anything, though, the power of convention isn’t without peril. When Rails makes it so trivial to do so much, it is easy to think every aspect of an application can be formed by precut templates. But most applications worth building have some elements that are unique in some way. It may only be 5% or 1%, but it’s there.

…

With so many controversial ideas to its credit, Rails could quickly become an insular group of ideological hermits, if we required everyone to exhibit complete deference to all tenets, all the time. So we don’t!

We need disagreement. We need dialects. We need diversity of thought and people. It’s in this melting pot of ideas we’ll get the best commons for all to share. Lots of people chipping in their two cents, in code or considered argument.

There is no “right way” to build an Ember app. You are not “doing it wrong” if you want to use GraphQL or Redux or MobX or TypeScript or Flow or Mocha just because that’s not what comes out of the box. No one but you knows whether a particular tool will make you and your team more productive.

In fact, you’re actively contributing to Ember because experimentation is a fundamental part of the process of incorporating the best ideas from around the JavaScript ecosystem. If people think they’re going to be scolded or made fun of for using the “wrong” technology, they’re going to take their ideas elsewhere, and it will be our loss.

Now that I’m a little older and a little wiser, let me say: mea culpa. I’m sorry for the times I’ve been flippant about other technologies, because it set a tone and a culture that we need to get past. The React, Angular, and Vue communities, and the wider JavaScript ecosystem, are doing incredible work, and we do a disservice to ourselves if we don’t follow along and borrow their good ideas.

We will continue to add primitives and stabilize private APIs in Ember, so that it’s easier for you to integrate with other tools while preserving the compatibility and shared solutions we value as a community.

While that happens, I have a request of you: whether it’s on Twitter, Slack, Discourse, or anywhere else we gather, validate the pain people are experiencing. Before getting defensive, acknowledge their frustration and offer to help—which has a tendency to defuse the situation altogether. If someone shares an experiment or an idea, encourage it or provide constructive criticism that is respectful of the work they’ve already put into it.

And if you see me or anyone else getting this wrong, call it out (gently). It’s a bad habit that’s easy to slip into, and we can only change our culture if we all help each other spot it when it happens.

As Sir Jony Ive said, “While ideas ultimately can be so powerful, they begin as fragile, barely formed thoughts, so easily missed, so easily compromised, so easily just squished.”

Let’s make sure we’re fostering a community that doesn’t squish ideas.

Would love to hear your thoughts and feedback.

Posts: 2

Participants: 2

Read full topic

@jessica wrote:

Hello once again to Readers’ Questions, presented by the folks at The Ember Times with a little help from the Ember Core Team and Friends

Today I’ll be answering a question by Ilya:

Why does Ember use Broccoli and how is it different from Webpack, Rollup, Parcel?

Tools which are often used for packaging JavaScript applications like Webpack, Broccoli, Rollup and Parcel differ in many aspects. Let’s take a look at some of the most striking ones:

Bundlers versus Asset Pipelines

Probably the most essential difference between Broccoli on the one hand and Webpack, Rollup and Parcel on the other is their use case. Webpack, Rollup and Parcel can be seen as bundlers - utils that help their users to concatenate assets together and allow for optional transforms like ES6 transpilation or CSS processing via plugins - whereas Broccoli can be described as an asset pipeline.

In contrast to asset bundlers, an asset pipeline like Broccoli is by default agnostic about the type of files and transforms that are managed in a particular build. Since Broccoli provides a functional programming API that allows users to chain different code transforms through plugins, any kind of build steps can be embedded into its pipeline. This also means that Broccoli can even leverage bundler libraries like Webpack or Rollup themselves as transforms.

This means that Broccoli can also be used for file transformations which go beyond the common use case of packaging JavaScript applications. Bundlers like Webpack or Parcel are more specialized and developed for bundling JavaScript projects in particular.

Differences in Developer Experience

Tools that are often used for JavaScript packaging vary in regards to their developer experience: The functionalities of asset bundler libraries like Webpack or Rollup can be extended further to apply additional code transforms via modules, plugins or loaders that need to be installed additionally. Parcel allows zero-config builds, inclduding asset bundling, code splitting and transpilation via Babel. It leverages a default build configuration (which of course can still be extended beyond the default settings) and makes the use of a separate configuration file for your first build obsolete (1).

In contrast to Rollup, Webpack and Parcel, Broccoli is an asset pipeline and can be configured through an imperative API. This allows users to chain build steps and integrate all kinds of transforms, like transpilation or CSS postprocessing (2) thanks to a pretty extensive plugin ecosystem.

Differences in Performance

Tools used for bundling or building JavaScript apps also differ in their performance metrics. e.g. in the amount of time needed to build and re-build a certain project. According to the ParcelJS documentation and other benchmarking tests Rollup might be one of the fastest bundlers as of date (3).

It makes a lot of sense to take these metrics with a grain of salt though: Build times can vary significantly depending on the size and structure of the application built, the transforms used in the pipeline, the system specifications of the machine the test is run on and which kind of caching strategies were leveraged. This means that if you try to take performance into consideration when deciding for one tool over another, it makes sense to run your own benchmarks and see how it works for your project first!

Why does Ember use Broccoli?

To some part historic reasons play into the adoption of Broccoli: As early as with the 1.11 release of Ember, Ember CLI has been adopted as the build and scaffolding tool for creating Ember apps. What was back in early 2015 still a rather novel workflow for developing JavaScript applications, turned out to be one of the biggest strengths of Ember as a framework and similar approaches have been adopted in many other JavaScript communities since then.

Broccoli used to be one of the few asset pipeline solutions around back in the day when the Ember community decided to adopt Ember CLI as an integral part of the ecosystem. It has since then proven to be extremely useful to let developers develop their Ember apps with ease. Since Broccoli as an asset pipeline is extremely flexible, it is possible to swap in the best tools and transforms available anytime without forcing end users to rethink their build system.

Which Bundling Solutions Are Used in Other JavaScript Eco Systems

As of date a variety of bundling solutions is leveraged in different JavaScript ecosystems; whereas command line solutions like Angular CLI, Aurelia CLI or create-react-app are making use of Webpack for scaffolding projects, utils in the Ember ecosystem like ember-cli-cjs-transform or Ember CLI are utilizing Rollup.js or Broccoli respectively.

In the past the question on using Webpack instead of Broccoli in the build process for Ember apps has been raised. One of the main arguments has been that it was not possible to provide features like code splitting, tree shaking and improved bundling strategies through today’s build pipeline (4). However, the upcoming 2018 Roadmap for Ember CLI aims to tackle exactly these issues to bring the functionality of Ember CLI fully on par with the feature set of other build tools (5).

Further Reading

Be sure to check out this excellent talk at EmberConf 2014 by Broccoli creator @joliss introducing the concept and motivation of using Broccoli’s pipeline strategies in Ember CLI. You can also read up more about the original architecture of Broccoli in this stellar blog post.

If you want to learn how to create your own build pipeline with Broccoli, then @oligriffiths’ amazing Broccoli tutorial is a must-read for you.

If you want to learn more about how the Broccoli build in Ember CLI works exactly, then be sure to watch @brzpegasus talk “Dissecting an Ember CLI Build by Estelle DeBlois” which gives an outstanding introduction into its feature set and setup.

Sources

• 1: Qualitative Comparison between Rollup, Parcel and Webpack
• 2: Broccoli.js Tutorial by Oli Griffiths
• 3: Performance Comparison between Rollup, Parcel and Webpack
• 4: RFC for Improved Learning Story in Regards To Ember CLI
• 5: Ember CLI 2018 Roadmap

---

This answer was published in Issue #62 of The Ember Times. Don’t forget to subscribe to the newsletter to get new Readers’ Questions and other development news right to your inbox. You can also submit your own questions! You will find a link at the bottom of the newsletter.

See you in the next issue!

Posts: 1

Participants: 1

Read full topic

@Nacho_B wrote:

Hello: I am suffering a lot trying to get ember-simple-auth working with my back end (Perl Mojolicious). I have problems in both ends.

But now I am thinking if all this tokens travelling back and forth worth the effort.

The Ember site and the back end are running in the same server and domain, for now and in the foreseable future. Most ot the articles about OAuth2 security talk about distributed architectures and remote apps but my site is almost monolithic.

Can it be done easily with cookies or sessions, as in a standard website?

At least until my ember proficency raises

Thank you in advance! Nacho B.

Posts: 4

Participants: 3

Read full topic

@Charles_Bourasseau wrote:

Is that possible to pass property by references to other object.

Something to achieve this:

import EmberObject from '@ember/object';

const Person = EmberObject.extend();

let personA = Person.create();
let personB = Person.create();

personA.set('foo', 'bar');
personB.set('foo', personA.getReference('foo'));

personA.get('foo'); // bar
personB.get('foo'); // bar

personA.set('foo', 'baz');

personA.get('foo'); // baz
personB.get('foo'); // baz

Posts: 3

Participants: 2

Read full topic

@Aquaman wrote:

I am sending a request to create a new record to an API. This call is successful and returns a uuid for the newly created record. I want to update the local store with the uuid. I am using normalizeResponse is my serializer like this:

normalizeResponse(store, primaryModelClass, payload, id, requestType){ if (requestType === ‘createRecord’) { console.log(payload.uuid); // this shows the uuid being returned from the API

} return this._super(store, primaryModelClass, payload, id, requestType); }

I would have expected the store to update the model (uuid exists in the model) but it does not update. What do I need to add to make the model update with the returned uuid? Note: the uuid is NOT the primary key in the record.

Posts: 4

Participants: 2

Read full topic

@Chrizzis wrote:

I am working on a project where we have a style guide that we are trying to make available to our ember app. The app has a couple of in-repo engines and an I am creating an in-repo addon that will contain shared components.

My first thought was to add the style guide to the shared addon and make the styles accessible to the host app, the engines, and the components in the shared addon.

We are using ember-cli: 3.1, ember-cli-sass, ember-css-modules, ember-css-modules-sass.

Can someone point me in the right direction on this? Is this even possible?

Posts: 2

Participants: 2

Read full topic

@calmwater wrote:

For some reason the search function is not working for me on Emberjs.com in the API reference. I have tried Safari and Chrome on macOS and it just sits there. No response to keypress, text entry or return key.

Posts: 2

Participants: 2

Read full topic

@ryanto wrote:

This sounds like a question from 2005 Ha!

Ok, we go…

It seems that there are a handful of different ways to configure how an Ember application makes its network requests. Here’s what I’ve seen so far…

• jQuery/$.ajax
• fetch
• Fastboot node fetch polyfill
• Fastboot njax

I’m writing an addon that makes ajax requests and I want to be able to do it in a way that respects all of these different environments. So far I’ve been using ember-ajax, but it was recently pointed out to me that it relies on jQuery, which a number of Ember applications are no longer using.

So that got me thinking, what’s the best way to make a network request in an Ember addon?

Posts: 3

Participants: 3

Read full topic

@anna wrote:

Is there a way to exclude files from the ember serve watcher?

We found using Windows machines that our build time was getting ridiculous. To help improve that we removed the scss compilation to an external watcher (which cuts our build time in half).

Unfortunately however running ‘ember serve’, when the other watcher rebuilds the files ember detects that and rebuilds it’s own code. Which is of course completely unnecessary since those files in no way affect it’s own compiled output.

Subsequently, is there way to prevent the rebuild if those files change?

Posts: 1

Participants: 1

Read full topic

@SarathSantoshDamaraj wrote:

I have an Object that has to be trimmed for white-spaces before updating/assigning with ember.set.

I know it can be done with using this.set(/**/).trim() . But just set() is not supporting trim() . And I have been told this.set() is not a best way than compared to just set()

set(Object, Key, get(key, value)) is how my syntax is.

and get(key,value) returns a value that has white spaces in it.

Posts: 1

Participants: 1

Read full topic

@Boo wrote:

hello, I need to create background as yellow while selecting the gear icon for the menu option in the table row, I have tried the below code for highlighting the table row,

var view = Core.view.Menu.create({
    model: model,
    menuContext: { lmdd: lmdd },
    anchor: this.$(),
    highlight: this.$().parents('tr:first').css('background-color','yellow')
});
view.show();

While selecting the menu, the background color is coming well. But when I move for the next table row, the past table row color is still in yellow color, not getting disappear. Can anybody suggest me code for this. I’m using Ember 1.4.0

Posts: 1

Participants: 1

Read full topic

@papakay19 wrote:

Please i’m have a template lint error with this line of my code

{{partial "-sales-table-header"}}

Ember 3.4.1 Ember Cli 3.4.1 Ember Template lint 1.0.0-beta.1

Posts: 1

Participants: 1

Read full topic

@ryanto wrote:

I’ve noticed in most Ember applications I work on there seems to be two common ways of wiring up actions.

Action 1: onclick
<button onclick={{action "myAction1"}}> Action 1 </a>

… and …

Action 2: action in element space
<button {{action "myAction2"}}> Action 2 </a>

From what I can tell, the difference between these two buttons is that Action 1 is a little more low level. It will not prevent the default browser event and when it invokes myAction1 it will pass the event as an argument. Action 1 also has the perceived benefit of being more in line with “just html and js”

Action 2 on the other hand prevents the default browser behavior and does not give the developer access to the event.

I’m wondering if there are any best practices here for when to use each style of action?

I’m thinking that the onclick style should be used when you need access to the event or want the default browser behavior. This makes senses in when working with actions attached to elements like select dropdowns, because you would want the event to get the selected option. See this excellent blog post by @balint

And {{action}} in element space makes sense for things like buttons, where you want a click to trigger an action, but don’t need to be concerned with the event or browser default. The guides use this style of {{action}} in element space for wiring up a button.

So how does that sound… What am I missing? When do you use onclick vs {{action}} in element space?

Posts: 3

Participants: 3

Read full topic

@kishoreyuvan wrote:

In my host app repository, I have an in Repo lazy loading engine.

When I proceed transition from my host app to engine’s route with Query param of type object for the very first time, It shows the error like

SyntaxError: Unexpected token o in JSON at position 1

And if i do the same again, its working fine.

Actually, I found that router._queryParamsFor(handlerInfos) method in “router.js” returns the empty objects(“map” and “qps”) for the first time, host app tries to transtion to engine’s route.

For the next time, it returns the value for the objects(“map” and “qps”), this is happening becuase engine’s instance is already created by the previous transition.

Also, if _queryParamsFor method returns empty object. Since, there is no type check for an object in _serializeQueryParam. It will return the string as “[object object]”. .

_serializeQueryParam(value, type) {
   if (value === null || value === undefined) {
     return value;
   } else if (type === 'array') {
     return JSON.stringify(value);
   }

   return `${value}`;
 }

How can I proceed the transition to an engine route with object type QP?

Posts: 1

Participants: 1

Read full topic

@samselikoff wrote:

I’m trying to figure out how to make a Sass file from my addon available so that other addons can @import it.

• If I put it under addon/styles/addon.scss, it gets auto-concat’ed into vendor.js
• If I put it under app/styles/my-addon-name.scss, then the host app can explicitly @import it. (But I’m trying to get an intermediate addon to be able to @import it.)
• I’ve tried putting a test file under addon/styles/foo.scss and configuring a second addon’s importPaths to point to that location, to no avail.

I’m trying to understand at a higher level the flow/architecture that these style trees. I think that would help me narrow down the config I need.

So to start, let’s say Addon B depends on Addon A. What hook/tree should Addon B look for *.scss files in Addon A’s addon/styles folder?

Posts: 3

Participants: 2

Read full topic

@pablobm wrote:

Hello there. I’m doing some research of the bowels of Ember, and I have a question about how @ember/routing/route implements store.

I understand this implementation is normally expected to be overriden by Ember Data or what have you, and that it’s considered legacy, but still I’d like to know about the history of it.

So specifically: why this line? https://github.com/emberjs/ember.js/blob/f73d8440d19cf86a10c61ddb89d45881acfcf974/packages/@ember/-internals/routing/lib/system/route.js#L1687

modelClass = modelClass.class;

From what I can see, all it achieves is to throw the container out of the window (as the result of .class won’t have access to the container), which limits the usefulness of the result at all, if I understand correctly.

Thank you!

Posts: 1

Participants: 1

Read full topic

@ryanto wrote:

I’m writing an addon and I need to know at runtime which version of Ember the host app is using. I’ve got myself in a funny situation. I can think of a few ways to proceed, but I just wanted to do a quick gut-check here.

My addon’s test suite runs against multiple Ember versions with ember-try.

When running tests against 3.1 I need to use

import Ember from 'ember';

console.log(Ember.VERSION);

When running tests against 2.16 I need to use

import { VERSION } from `@ember/version`;

console.log(VERSION);

If I try to use the 3.1 way in 2.16 I get an ember eslint error. It wants me to use the new modules syntax.

If I try to use the 2.16 way in 3.1 I get a module not found error.

I’m working around this now, but I’m wondering how addon authors approach these sort of issues when working with multiple Ember versions? Also, is there an opportunity for me to provide a polyfill here?

Posts: 2

Participants: 2

Read full topic