This week we're discussing 4️⃣ fresh RFCs 🥑: bringing truth helpers to Ember core ✍️, new error handling methods 🚨, jQuery-free Ember apps by default 😄, and some improvements to relationship links 🔗. We're also highlighting test coverage for docs when Ember is upgraded 🚧, the new ember-self-focused addon 👁🗨, the EmberConf 2019 CFP brainstorm 🧠⛈, and more...read on!
If you find yourself often reaching for the addon ember-truth-helpers in your templates then this new RFC by @cibernox is for you. This Request for Comments (RFC) proposes bringing in some of the template helpers in ember-truth-helpers into Ember Core.
The reasoning behind this is that a few helpers from this addon are so common in Ember apps that it makes sense to add them into Ember Core itself to reduce the friction of needing to install an addon to get them.
Another reason that might even be more important is that this could open up Glimmer VM low level optimizations as the Glimmer VM itself would know about these helpers.
The proposed helpers to add to core are: eq, not, and, or, gt and gte, lt and lte.
A recent Request for Comments (RFC) from the magical Ember Data Land takes us on a journey through error handling in Ember: It proposes the addition of new error handling methods which do not affect the state of your data records to the DS.Errors class.
Previous RFC-driven efforts already provided an option for you to exclude jQuery from your Ember app builds easily (1, 2, 3). Now a follow-up RFC takes the idea of reducing the initial bundle size of apps even further.
The new proposal envisions apps to provide an easy opt-in for the UI library, but to exclude jQuery by default. The RFC suggests that this will make it easier for developers and addon authors to provide smaller apps from the start and only include the dependency back in if it is really needed.
You might have noticed that sometimes when a new release of Ember is out some API documentation can disappear. This happens when code gets moved around in Ember, such as putting functions in their own modules, which makes it easy to make mistakes that impact the documentation parser. @ef4 added test coverage for exactly these cases.
This means that when a new release is prepared these tests will most likely catch any unintentional documentation changes.
Fetching your data from a JSON:API compliant backend? Not sure how to tell Ember Data explicitly to look up an included relationship in the payload itself vs. via an additional request using the response's link attribute?
Possibly, this will be much easier very soon! Another new, Ember Data related RFC proposed the addition of a shouldFindViaLink method to the public API of REST adapters. According to the proposal, users may overwrite this method - which should return a Boolean to indicate if Ember Data should look up relationship data via links or not - themselves for custom behavior and gain full control of their relational data loading.
User interface transitions that happen in a single-page application (SPA) are problematic for screen reading software since traditionally they are reliant on reading out the text on page load. Since there are some visual changes on the screen but the page does not reload in an SPA, it makes it difficult for screen reading software users to be aware of UI changes.
To solve this issue, @sarbbottam released a brand new addon to enable screen reading software to speak the content of the new node by focusing on the HTML node of the dynamic content. The new addon ember-self-focused provides a component and a service to keep track of the HTML nodes to be focused.
Interested in submitting a talk idea to EmberConf? Join the EmberConf team for an interactive video brainstorm on Tuesday, October 30th at 11:00am PT. They'll chat about the CFP, the topics they hope to see, and answer community questions about ideas and proposals. Mark your calendars and go to the EmberConf website for more info!