Add June Learning Team agenda

[amyrlam]

No description provided.

[chriskrycho]

I’m planning to attend, and would love to put this on the agenda:

### replacing `ember-ref-modifier` (CK)

One of the advanced examples in the guides, [Communicating Between Elements in
a Component][example], uses `ember-ref-modifier` to show how to implement some
custom functionality. This example dates to a time before the existence of
`ember-modifier`, and was reasonable to include at the time. However, today the
example can be implemented much more cleanly using a class-based modifier from
`ember-modifier`. Just as importantly, using `ref` has significant performance
implications that are *not* obvious: it requires two rendering passes. I’ve had
to wave people off of using `ref` a couple times already in our app as we adopt
Octane, because it’s officially recommended in the Guides, which we point people
to as our *first* source of truth for how to write Octane. I suggest we remove
it in favor of another example using one of the `ember-modifier` variants.

[example]: https://guides.emberjs.com/release/components/template-lifecycle-dom-and-modifiers/#toc_communicating-between-elements-in-a-component

[rwjblue]

FWIW, I share @chriskrycho's opinion / concern.

[jrjohnson]

Yes please! As it was suggested in the guides we used it in our Octane migration and have been unpleasantly surprised by race conditions several times. Though my alternative proposal is to make it work more with less surprises

[chriskrycho]

Yeah, that would also be a possible win! As I'll elaborate in the meeting, even without those particular performance surprises I think using ember-modifier and properly encapsulating the interesting bits is likely always going to be the better move, though. 😅

[lifeart]

For note: If it will be replaced, we need to add note about - “dom” property can’t be tracked, because of emberjs/ember.js#18698

Currently modifiers logic running on the end of rendering in same transaction, and if tracked property have been accessed before setting it, it will throw error.

There is a case to detect is property tracked or note, but I’m not going forward with it because there is no feedback lifeart/ember-ref-modifier#232 (comment)

Original ref modifier implementation worked without scheduling, but this behavior siding on mentioned cases.

Between performance and stability I choose stability (for novice users), and if use cases has strong perf degradation - it’s really preferable to not use ember-ref-modifier.

Discussion - lifeart/ember-ref-modifier#203

Anyway I'm open to any suggestions, and if there is agreed concern about changes inside ref-modifier or eliminating it from official documentation - I'm with you.

I understand that this repo is not the case for single-person decision making, and I'm also open to transfer it to any organization (if needed).

[mehulkar]

leaving initials blank as i'm not sure i can actually be at the meeting, but would still like to nudge the team forward into thinking about it and giving the community an update.

### Ember CLI API docs (?? - 10mins)

I want to get an update on getting API docs on `https://api.emberjs.com/ember-cli`
and redirecting `ember-cli.com/api`. As embroider approaches and the larger
JS community experiments with JS development (e.g. Snowpack), it is
important for the Ember project to _enable_ its community to experiment also.
Moving the API docs to the main site will make it easier to improve
documentation, add examples, and propose API improvements that can
enable such experimentation.

[amyrlam]

Copied the topics in. Please use GitHub suggestions if any adds/edits!

[amyrlam]

@chriskrycho @rwjblue @jrjohnson @lifeart @mehulkar @ijlee2 in case you're attending, it sounds like we may be meeting on Discord voice channel (not sure what it entails yet! but is different from the link on the calendar invite), so please check out #dev-ember-learning on Discord tmrw