Be sure to join the new Ember community chat on Discord 💬! This week, you can have a look into Ember Data's Meta Quest 🔜, some fresh 🍎 RFCs, thoughts on fostering the Ember community 💛, and a special thank you to @mmun 🎉.
The Ember Data team is looking for community help to bring RecordData to a stable release! You can read more about RecordData in RFC #293. RecordData codifies the internals of Ember Data, giving addon developers needed API access with more confidence and stability.
Community action items:
Once 3.5.0-beta.2 is released, configure your apps/addons to test against this version!
Report errors encountered, and help triage/replicate as much as possible.
Help refactor existing addons to utilize RecordData instead of likely-removed intimate APIs. For a good starter list, see Ember Data's external-partner tests.
@davewasmer has written a RFC introducing the concepts of editions. The idea is that every few years Ember will declare a new edition of Ember that bundles up accumulated incremental improvements into a cohesive package.
The benefit of this being that this gives the Ember Community an opportunity to bring our documentation and marketing up-to-date to reflect the improvements we’ve made since the previous edition. According to the RFC, the right time to declare a new edition is when:
A significant, coherent set of new features and APIs have all landed in the stable channel.
Error messages and the developer ergonomics of those new features have been fully polished.
Tooling (the Ember Inspector, blueprints, codemods, etc.) has been updated to work with these new features.
API documentation, guides, tutorials, and example code has been updated to incorporate the new features.
The RFC to deprecate computed overridability and readOnly() seeks to align computed properties to the native class syntax getters and setters by deprecating computed overridability (colloquially known as "clobbering") and make computeds read-only by default turning this uncommonly used feature to an opt-in using the overridable API.
Similarly, the RFC to deprecate computed().volatile() was proposed to favour native accessors rather than relying on the volatile API to provide that functionality. This is to align what users expect a property does when it's value changes versus what the framework does, including notification changes.
With this topic in mind, Tom Dale shares the following thoughts:
Everyone is encouraged to share their thoughts about the framework and the path it's taking, even if it is to disagree with the core team or with the community in general, the community will fail if people believe they have to stay silent.
It is dangerous when developer communities create mantras that they repeat endlessly, as the original context around the why can get lost, and then people can tend to postulate the mantra without knowing its original purpose forgetting that underlying assumptions behind it can change.
There is no "right way" of building an Ember app, no one but the developer in question knows better what are the particular tools that are necessary to make the team more productive and a project a success.
We should put ourselves in other's shoes to understand the frustration other people experience and offer to help and provide constructive criticism, before getting defensive.
The big tent analogy used, meant that Ember is an open community that welcomes different individuals with different thoughts and opinions about the framework and the correct way of leveraging it for our own projects.
Although Ember comes with a set of defaults and guidelines, it is unrealistic to think that those same defaults fit every project in every situation.
Quoting Tom on his final reasoning: "Let's make sure we're fostering a community that doesn't squish ideas."
Since his first pull request to the ember.js repository - submitting a bug fix for failing tests for the former ember-views package - Martin has been an actively contributing to Ember and related projects. In June 2015 Martin joined the Ember Core Team and dedicated his time to help Ember become the framework and the community we ❤️ today. We're grateful for all the hard work he had put into the project, but also for all the understanding, support and compassion he has shown to anyone in the community each day. With this we'd like to say once more: thank you, Martin!