alex for Ember apps 🤔💭
yohanmishkin/code-quality-challenge 2
Challenges from "The 30-Day Code Quality Challenge" https://www.codequalitychallenge.com/
yohanmishkin/github-major-keys 1
Some missing keyboard shortcuts for github
yohanmishkin/mandatory-elegance 1
Elegant Objects static analyzer for .Net
Object oriented email for .Net (vague port of https://github.com/jcabi/jcabi-email)
startedmansona/lint-to-the-future
started time in 2 hours
issue commentemberjs/rfcs
`hasBlock` deprecation, documenting `(has-block` and `(has-block-params`
There is now an RFC for deprecating hasBlock
and hasBlockParams
.
comment created time in 3 hours
startedvega/ts-json-schema-generator
started time in 6 hours
pull request commentemberjs/rfcs
Deprecate {{hasBlock}} and {{hasBlockParams}} in templates
@jelhan - ya, totally agree! We'll need to ensure that the API docs are updated at the time the deprecation guide lands.
@pzuraq - Would you mind double checking the prose here to see if we need to explicitly call that out? I think it may be already included in the existing prose RE: "How we teach this", but would love a second set of 👀...
comment created time in 8 hours
issue commentemberjs/rfcs
To include ember-template-inspector in ember-inspector
Maybe even the Ember Inspector could show the template of the component directly? Maybe it could even show the current value of a property / argument when hovering over it in the template? :exploding_head:
comment created time in 14 hours
Pull request review commentemberjs/rfcs
Deprecate {{hasBlock}} and {{hasBlockParams}} in templates
+---+Stage: Accepted+Start Date: 2020-12-22+Release Date: Unreleased+Release Versions:+ ember-source: vX.Y.Z+ ember-data: vX.Y.Z+Relevant Team(s): Ember.js+RFC PR: https://github.com/emberjs/rfcs/pull/689+---++# Deprecate `{{hasBlock}}` and `{{hasBlockParams}}` in templates++## Summary++Deprecate the `{{hasBlock}}` and `{{hasBlockParams}}` properties in templates in+favor of the `{{has-block}}` and `{{has-block-params}}` keywords.++## Motivation++`{{hasBlock}}` is a way to check if component has a default block provided to+it, and `{{hasBlockParams}}` is a way to check if that default block has block+parameters. They are effectively aliases for calling `{{has-block}}` and+`{{has-block-params}}` respectively, without providing a block name or with the+block name `"default"`. They are also not called, and acts like a template+fallback lookup instead.++```hbs+{{! hasBlock and hasBlockParams can be referenced directly }}+{{#if hasBlock}}{{/if}}++{{#if hasBlockParams}}{{/if}}+++{{! has-block and has-block-params must be called }}+{{#if (has-block)}}{{/if}}++{{#if (has-block-params)}}{{/if}}+```++Having two ways of accomplishing this task is confusing, and with the property+form it is not possible to check if other blocks exist, such as named blocks. As+such, this RFC proposes that we deprecate `{{hasBlock}}` and+`{{hasBlockParams}}` and recommend that users switch to using `{{has-block}}`+and `{{has-block-params}}`.++## Transition Path++Users who are currently using `{{hasBlock}}` or `{{hasBlockParams}}` will need+to replace all of their usages with `{{has-block}}`/`{{has-block-params}}`+respectively. This is generally a very codemoddable change, so it should be+pretty straightforward to accomplish, and we will attempt to make a codemod to+help out with the transition.++## How We Teach This++### Deprecation Guide++#### `{{hasBlock}}`++The `{{hasBlock}}` property is true if the component was given a default block,+and false otherwise. To transition away from it, you can use the `(has-block)`+helper instead.++```hbs+{{hasBlock}}++{{! becomes }}+{{has-block}}+```++Unlike `{{hasBlock}}`, the `(has-block)` helper must be called, so in nested+positions you will need to add parentheses around it:++```hbs+{{#if hasBlock}}++{{/if}}+++{{! becomes }}+{{#if (has-block)}}++{{/if}}+```++You may optionally pass a name to `(has-block)`, the name of the block to check.+The name corresponding to the block that `{{hasBlock}}` represents is "default".+Calling `(has-block)` without any arguments is equivalent to calling+`(has-block "default")`.++#### `{{hasBlockParams}}`++The `{{hasBlockParams}}` property is true if the component was given a default block,+and false otherwise. To transition away from it, you can use the `(has-block-params)`+helper instead.
```suggestion
The `{{hasBlockParams}}` property is true if the component was invoked with block
params for the default block, and false otherwise. To transition away from it, you can
use the `(has-block-params)` helper instead.
helper instead.
comment created time in 14 hours
pull request commentemberjs/rfcs
Adding Equality Operators to Templates
I think this might be overthinking it.
Hehe, I don't disagree with you (see my personal note in that snippet); buuuuuutttt sometimes it's what we do. 😺
comment created time in a day
push eventemberjs/rfcs
Deployment Bot (from Travis CI)
commit sha 6f9fb911727d9d8e2b5ca2e74c0290b4670fa026
Deploy emberjs/rfcs to github.com/emberjs/rfcs.git:gh-pages
push time in a day
pull request commentemberjs/rfcs
Adding Equality Operators to Templates
Do we have to consider that two helper invocations are guaranteed to be eq to each other? In other words, if we have {{#let this.whatever as |thing|}}{{if (eq thing thing)}}{{/let}}; should the rendering engine even run JavaScript code to determine these are equal or should it assume that they are eq (aka stable) and therefore we can optimize the rendering engine output to avoid the extra comparison. 🤔 (personal opinion note: I think that this may well be true, fine, and awesome; but doesn't have to change anything about this RFC...)
I think this might be overthinking it. First, IDK if helpers are guaranteed to have stable outputs, at least with class-based-helpers I believe you could perfectly not be the case. Trying to be that smart just to remove a == operations seems overkill.
comment created time in a day
startedprotocol/beyond-bitswap
started time in a day
push eventemberjs/rfcs
commit sha 333d55a62dbcefad3f6d8760ccd4a24d16d0dfb2
Fixup metadata on recently merged PR
commit sha cdcdef93d145527bb65a24070ad2d7cd0900156b
Merge pull request #708 from kategengler/kg-fix-rfc-metadata-jan-15 Fixup metadata on recently merged PR
push time in a day
pull request commentemberjs/rfcs
Modernize built-in components (part 2)
We discussed this at todays core team meeting, and are moving it into final comment period.
comment created time in a day
pull request commentemberjs/rfcs
We discussed this at todays core team meeting, and are moving it into final comment period.
comment created time in a day
pull request commentemberjs/rfcs
Deprecate jQuery Integration Optional Feature
We discussed this at todays core team meeting, and are moving it into final comment period.
comment created time in a day
pull request commentemberjs/rfcs
Deprecate Octane Optional Features
We discussed this at todays core team meeting, and are moving it into final comment period.
comment created time in a day
pull request commentemberjs/rfcs
Deprecate {{hasBlock}} and {{hasBlockParams}} in templates
We discussed this at todays core team meeting, and are moving it into final comment period.
comment created time in a day
pull request commentemberjs/rfcs
Adding Equality Operators to Templates
We discussed this a bit more this week, and are still very much in favor of moving forward.
IMHO it's complicated enough to explain that empty arrays in HBS are falsy. if equality was also redefined to work different from == and === it would make it even harder to explain to new devs.
Agreed. I think this is well stated, and when we discussed it more at todays meeting we shared your conclusion.
Remaining questions that we want to resolve (either in a GlimmerVM team meeting or the next core team meeting):
- Should we use
Object.is
instead of===
? The main difference betweenObject.is
and===
is comparison with +0 or -0 and NaN (which are all pretty WAT in normal JavaScript). Most folks have no clue thatMap
/Set
/WeakMap
don't use===
(they useObject.is
), and it doesn't cause any issue. - Do we have to consider that two helper invocations are guaranteed to be
eq
to each other? In other words, if we have{{#let this.whatever as |thing|}}{{if (eq thing thing)}}{{/let}}
; should the rendering engine even run JavaScript code to determine these are equal or should it assume that they areeq
(aka stable) and therefore we can optimize the rendering engine output to avoid the extra comparison. 🤔 (personal opinion note: I think that this may well be true, fine, and awesome; but doesn't have to change anything about this RFC...)
Hopefully, we'll be able to resolve those two issues at the next round of meetings.
comment created time in a day
push eventemberjs/rfcs
Deployment Bot (from Travis CI)
commit sha 74237c62db0c919009c492fa83c7cadfdc813076
Deploy emberjs/rfcs to github.com/emberjs/rfcs.git:gh-pages
push time in a day
push eventemberjs/rfcs
commit sha ad6ba28fcd5c9c8d550a8d636e7ac6d6ff305926
Adding Logical Operators to Templates
commit sha 8a344d1b652ced85275cc3d712a59f220ea9ea45
Update text/0000-add-logical-operators.md Co-Authored-By: Chris Krycho <hello@chriskrycho.com>
commit sha 64a723035ee8266e34894a5972f0490ecae222ec
Remove confusing part about bound/unbound arguments.
commit sha 53ec1bf554d0d64a9aa8db6cdfbbfd7250f0e2a9
Add note on the alternatives: Allow lazy-evaluating args in userland helpers
commit sha 3fb0ad14f17cec22cac6b792841819da74abc59d
Update text/0000-add-logical-operators.md Co-Authored-By: Godfrey Chan <godfreykfc@gmail.com>
commit sha 41e6f828d05d9a53df28fff625c9b6b768034cd4
Improve teaching section
commit sha 5a0f6f8dda92edf11f870241e78b03881abd973a
Merge pull request #562 from cibernox/add-logical-operators-to-templates Adding Logical Operators to Templates
push time in a day
PR merged emberjs/rfcs
Extracted from RFC #388
pr closed time in a day
push eventemberjs/rfcs
commit sha 7856ddc75bd067d2fbe8bfc6c003038ac086cd4e
deprecate attrs in templates
commit sha 1972114794febe6748f3fe80fc0e2aaa2cb5f4a6
update filename and add PR
commit sha 3254432dcdc322ab07aa8b878072bc6c68aa0bb8
Merge pull request #690 from emberjs/deprecate-attrs-in-templates
push time in a day
PR merged emberjs/rfcs
pr closed time in a day
delete branch emberjs/rfcs
delete branch : deprecate-legacy-class-binding-curly-invocation
delete time in a day
push eventemberjs/rfcs
commit sha 86a985ebdf3876bd643afa8f0ee212682dfa92dd
Deprecate passing `classBinding` and `classNameBindings` as arguments
commit sha 7cf85d3b255c5711502368bbbb06081d762fb6c5
update filename and add PR
commit sha 6b8154e18ffcdd89734814a921f5c235cb58ef54
Update text/0691-deprecate-class-binding-and-class-name-bindings.md Co-authored-by: Jarek Radosz <jradosz@gmail.com>
commit sha 0dee846f8b35f08ff2756b2eaaf20e5cb6a6ca30
switch to class attribute
commit sha 94cb144337992389edfc12a75d605fb9b5963dda
Merge pull request #691 from emberjs/deprecate-legacy-class-binding-curly-invocation
push time in a day
PR merged emberjs/rfcs
pr closed time in a day