 Okay, so a couple of full disclosures here first of all, this is not a keynote or PowerPoint presentation That is because I did not really have time to prepare one. However That's the full disclosure however, I realized when I was thinking about this talk that probably a useful thing to do in general is just to give a survey of Open RFCs that are probably gonna start moving So like you've probably heard at various big events like ember comp or whatever big things that we're working on like fast boot or Engines stuff that we talk about but there's a billion things that we do Just to run the project that you we don't talk about a lot and actually that a lot of that stuff has gotten a little bit backed up as Because everyone's been focused so hard on glimmer. So I figure just give an update on where all that stuff stands So I just took a few interesting things out of the open RFCs that I think are probably gonna move We also have a meeting face-to-face meeting this weekend Me and Godfrey will be there and other core team members and I think this is a pretty good represent representation of the stuff That will come up. So I'm trying to cover things that I think are Getting close to being either landing or getting a lot of attention paid to them So basically as you probably know almost everything in ember that happens happens via RFCs So basically anything that I could talk about that is even plausible to land anytime in the near future already must have an RFC With one notable exception which I'll get to soon Which is actually pretty cool It basically means that if you want to understand like obviously that's a much bigger list than I'm already talking about today So you have to have a sense of which things are moving and which things are languishing But you can get a sense of sort of where people are at what people are thinking what community members are suggesting basically the ideas for ember come from a lot of different places and The RFC process being a pretty open place for people to just toss some ideas in and let them Marinate has been a big part of I think why ember is so robust. So The first RFC that I want to talk about is the module naming standardization effort It actually has a very low RFC number because in principle It should have been done a long time ago We were like mega early adopters, sorry, you guys are all drop boxing on my internet, sorry There we go So it's very early. It's like I don't know More than a year ago We were ember was a pretty early adopter of ES6 modules like before they were really ES6 modules I'm actually pretty proud of that and how it shaped the final spec But what that sort of meant is that because we were so early adopters there was never any really good time for us to be like Okay, now that everything settled down. Let's do the standardization and then we got busy with glimmer too. So the idea behind the this RFC is that Today you do something like that and basically act as if there is still an ember global even though there is not and The idea is that we will do something like this I think the the reason why this is language is that this is like the most epic bike shed You could possibly imagine it's like oh we get to redesign the entire surface area of the entire ember And also we can remove things if we don't like them or while we're at it We could also fix bugs because now it's a totally new API. So that's sort of why this has been a pretty big thing But the idea is basically to make the API more component ish. Sorry more module ish There's been a bunch of different proposals for how to go about dealing with this There's different ways of doing the nesting basically and I think for sure if you are interested in a bike shed This is a good one probably heat up again pretty soon one thing that I think is pretty interesting about this change is that in When we had a global's build basically the way that that was built and a lot of you probably can remember this is You create an object an empty object and then every module just says ember dot whatever equals whatever And what that intrinsically means is that you actually need to have Evaluated all the modules ahead of time because if ember dot component is not there then ember that component is not there Oh, well, sorry you're out of luck and Today the ES the ember CLI shims which I talk about here Ember CLI shims is an add-on that you can install that the ember CLI team includes I think it might even be included in ember CLI by default although it's not not a final version That thing just shims those globals So basically that though all those imports are not able to take advantage of the fact that you're not actually that we now know What you're loading? And one of the nice things about doing this for reals is that we get to actually stop loading or evaluating code that you're Not using which I know it sounds like something we should have done a long time ago But it's sort of like this transition from globals to the ASX modules has been sort of in an incremental way, so This is going to be pretty cool I sort of basically everything in this presentation is pretty speculative in the set in terms of the surface syntax But I'm trying to get pretty concrete with at least with the speculation So you'll see some examples, and I don't we don't have an RFC for this I think this is going to be an even bigger bike shed than the module one But I really I think now that we have decorated to advance this stage, too We're pretty ready to really take on ESX classes, and I think we will do that I think that's gonna happen soon. I'll show you like basically the yuhuda theory of it But that's just you Okay, so so that's that I put this first because basically every example that I use Assumed some version of this landing and I don't want to have to explain it over and over again. So that's the first thing The second thing is this thing which is called module unification I think Dan called it that so that people wouldn't notice that it was important It's called also called sometimes new pods or new pod structure also like we have been working on this for a long time It's been included as a like an unstable option in ever see a life for a long time, and we are finally getting there. Let me Go to it. I Should have opened all these tabs at a time. Maybe I should I got to get Google web accelerator on Yeah, so you can also see by the way all these ones have a lot of comments Many happy happiness is attached to it So the basic idea behind module Unification which you can see Dan means all these things. I think like I said, so people don't notice but used there used to be another RC called module normalization Which was also important, but it got super seeded by this model unification thing You can see at the top we sort of get through all the things that people think that they care about there's like a lot of things people think they care about when we're talking about how to structure your code and Basically, there's a the idea is that it groups things that are similar to each other next to each other That's a deceptively simple description. This has I think been the hardest thing we have ever designed in ember Just because the file system name spacing is very tight, right? So you don't have a lot of options for you don't have a lot of options for Extra name spaces or I want a private thing here. How do I name that? I don't want to use the user's name space You don't have a lot of options for signaling I'm going into a component now without creating a whole new directory which could become very annoying so The amount of we did a lot of wordsmithing to get to a point what that I think people will like But I think people will also not like some things about it. And honestly, it's very it's hard So here's like a not I think very well formatted Thing there's a better So here's a maybe a more small a smaller thing you can get your head around right? So you the one of the things is that the new parent directory called source and the idea is that we can use the source directory to get People to incrementally transition so any benefits you get from transitioning you can get as you go Otherwise the app directory will still work as before And so we have some new categories. We have like UI and data things like that and then inside of UI there's Components probably the biggest the biggest conceptual change that you will notice is Today every component lookup is global So if you want to have a nested component and you want to refer to it in a way that it's not clobbering You have to use a pretty deep slash separated thing Which is pretty reminiscent of the dot separation before like in the old pre module days In the new in the modeling unification world You will automatically have access to any components that are nested directly below you So here's a component called it selected and it selected Actually, it's hard to read this I apologize, but basically it selected has access to Sorry, no that is wrong. I can't actually see the code I want to I'll jump to an actual application because I think there is one Yeah, so we actually redid a few different A few different actual apps to try to see how it would feel Which I think it's pretty cool actually Robert did a lot of that work So here's UI components, so here's all the like all their ghost things I'm probably gonna pick a bad one and that's gonna be sad Yep, I did It's gonna be a fun story. This should have a nested thing inside. Nope There's got to be something to have nested stuff anyway, I'm not gonna this is probably gonna be very annoying So the TLDR is if you have let's say a table and then inside of there You have like table rows and inside of table row you have table cells instead of having to have like my table slash my table row Slash my table cell if you put your table row next to the parent As a nested nesting and you put your table cell nest inside of there each one can refer to the thing That's right below it. It's sort of like like Local scope in the JavaScript program, but it uses the file system, so I think that I think that's actually pretty cool What one of the reasons one of the ways I arrived at that was I did a bunch of surveys of a lot of applications And looked at all the ways people were using slash and it's like more than 99% Slash represents it is a thing that is nested inside of me and that is what I'm talking about right now So basically what that means is that the for the most part just deleting all of your slashes would work Which I think is great all the prefixes You can still have global components, so if you put components directly underneath UI They're still there, but the idea is that if you look at actual apps most things are indested All right, so there's like your route and that has some nesting components Which has some nesting components very few are being shared very globally So the idea is that the number of things in your global Space will be pretty small compared to the number of things that are just part of your application structure So anyway, that's I think that's all pretty cool I believe that this I don't know if this still works I'm wary of suggesting things that who knows what their current state is but as part of this process Robert has created and maintained the migration tool that you could just like run against your app to see what happens And it tries pretty hard to do the idiomatic things with nesting things like that And the idea was basically just for us to get a sense as we were iterating on the proposal Like what an app would feel like and if it makes sense I think basically this whole thing is pretty visceral Problem and if you think that you like if you try to have reason about in your head you will not get it right Okay, so one pretty cool side effect of the module unification is That so yeah, it's pretty cool that we got that so tldr Incremental migration via app and source one pretty cool consequence of all that is that we're probably gonna get pretty good performance improvements out of this and the reason for that is pretty obscure and But it's that basically the loader API and the resolver API are things that are most people don't use big apps sometimes use them But most people don't use them directly, but they have to do a bunch of work every time you look up a module to figure out where it is and By standardizing the directory structure again, you are Allowed to use the old system you're allowed to use the old resolvers if you want but if you agree to opt into the the convention then the resolver that we That we use will be able to run on the server instead of on the client That means that all the all the resolution can be done on the server and I was I wrote here that includes stuff like Allows us to resolve components to handle parts in Texas build time so we see like food that's bar We can actually at build time figure out I see that that's that component and then there's no lookups at build time This is pretty notable because if you look at profiles and applications the look up The look up factory time like a time that takes to look up Modules and classes is very significant Some of that is just like evaluating things which we can't get around you're evaluating things no matter what But a decent amount of it is just like going like looking things up part splitting paths things like that. I Also really want for the like for the service our resolver to not be restricted to just being hard-coded to source So I think probably the way it will work is that it will be pluggable like the current resolver But it will be expected to run the server instead of being expected to run the client Which means that it will be restricted to stuff that you can tell by looking at the files and not runtime Turns out nobody needs the runtime stuff if you needed it you'd be in a pretty bad performance place anyway So basically it gives us an opportunity to do that. I think that's pretty exciting So grant testing unification is a thing that really should have landed a long time ago I think people just got busy on this The basic idea is to just actually use async weight that has now reached stage four So like it's actually starting to line in browsers now and The idea is that instead of Sort of so I actually don't mind like in terms of what we were working with I think the top syntax is pretty terse But I think a pretty it's pretty nice that the bot like the top syntax is effectively the same thing as the bottom syntax It actually doesn't even really increase the amount of size that much because the end-end blocks go away And they are just interleaved correctly So like the actual amount of characters is actually smaller in the bottom despite the fact You have to be explicit about a weight and I think that's pretty cool I've been working on a project recently. That's like all async await all the way through and it's like This indeed works as advertised So I think this is probably we're probably going to do more async functions over time like maybe the model hook could be async function Stuff like that, but I think there's like and you already could do that actually because the model hook is already with the thing That returns a promise. So if you just turn into an async function, it will just work But we're not going to go change all our docs to tell you that before thinking through it more I think the testing Framework is probably the first thing that's going to seriously get async Support and I think that's pretty cool. I think this Okay routing service so the thing about the routing service is that For like a year anytime anybody ever asked us for a routing feature We would be like, oh, we should really do that in the routing service And eventually someone was like is there an actual routing service or is this just the thing you said and we say That's just the thing we said So Edward Faulkner who is really great He's super rigorous wrote up a pretty long rfc a long time ago. It's pretty Pretty baked. I think people worked through it. We discussed it at pretty in pretty depth a lot of depth at the last face-to-face And the I think this the tldr is it gives you a public API for doing your own link to or whatever equivalent things like more complicated things It also lets you write like a cheaper link to if you happen to know that you only want a small subset of the Functionalities be pretty easy to write And also like at the same time Because link to is the main thing that is hooked into how transitions work. There's a lot of stuff about how that works I think the most notable one is We load When we have query programs, we actually load all the controllers to look at their Values to figure out what the default behavior what the default Value is but there's no actual reason for that There's no we just like oh it seems nicer to not include a query program if it's actually the default There's no actual reason why that's important other than a minor aesthetic consideration And it has a significant performance cost and link to is actually one of the most expensive things in ember. So Making a service allows us to think about what if we're making a totally new public api we can think about what the Expected behavior is for those things and I think that was good I actually think that particular one we can change in link to also But just making the service gave us a chance to think about what is what is going on And if you really need the old behavior will be easy to get Um Yeah, here is some more of my speculative syntax I think this is pretty cool. Um, it's basically just like the exact injection syntax, but as a decorator, which is pretty nice um, and then I think we can do this Okay, this is a really boring thing, but it's like a pretty important one it keeps it's come up and taken significant time of almost every face-to-face meeting in recent history So rc issue 125 was like hey look up factory is a thing and we made everything else on the container public Can we make look up factory public? And turns out the answer is no for very annoying reasons. Um We'll talk about them briefly, but it's pretty boring So first of all, this is not a public api We actually don't have a lot of things with underscores in them that you use that should be a pretty strong clue That you're doing something that's not public. However, it is a somewhat common thing that people use in practice And we call these things intimate apis which are like we know people use it We definitely didn't promise to maintain it, but we can't we don't want to break a lot of people's apps. So It is what it is Basically, it doesn't require us to make a sembler of breaking change, but we work really hard to mitigate the transition costs so Here's an example of like usage of this not public api And then here's like an example of someone using it so you can basically go and get a factory for whatever and If you create that thing it's an instance of article that seems good But the actual factory itself is not is not in fact articles a subclass of article That wasn't always true, but eventually became true During between when it wasn't true this api was not heavily used nowadays, but Basically the reason why you get a subclass is that we want calling create on that thing to actually get the registered injections for that Owner so if I registered some injections for my Components and I say give me the factory for the food component and then I create it I would like to get the registered injections and we actually register a bunch of injections for you And you're expecting to get them like if you subclass a route and create it Sorry, if you get a route and create it you expect to have the store on it Which is injected you probably annoyed if you didn't have the store and so we basically just the solution at the time Basically when we thought it wouldn't necessarily have to be permanent But was like ah it seems like okay solution for now is we just always subclass We always subclass the thing that you're looking up to add in whatever the owner's injections are for that thing That is ah and also additionally we want instance of the work And we also want for the most part for like state that's on that thing to appear to exist so We were like well We are We want we need these things to work and now it's basically like we never made a public api But it's now like there's no other public api So now there's a lot of usage of this in the ecosystem and we can't break it So we're like okay, we have this problem Which is this double extend thing now just just of note the reason why double extend sucks is because So that's the first thing here performance issue Is that we now are just subclassing tons of things for no reason and ember subclasses are not as cheap as ea Six couple classes, but anyway just like randomly creating extra subclasses all the time for one extra subclass per thing That you're using is extremely annoying and has performance classes. Um, just generally people it's bad to create new New kinds of things at runtime like ideally you get all your things out of the way in the beginning and then you use them Um, and this is a thing that creates like a lot of new kinds of things all the time Annoyingly like people rely a lot on the exact detail like people We thought oh, maybe we can get rid of double extends like no people actually rely on the fact that it's not the same thing Right, they'll like put stuff on it and then maybe like in a test or something. They'll rely on the fact that it's not there anymore So yes, very sad. So The solution is just leave underscore lookup factory alone Uh and make a new api that satisfies the use cases without creating new But without creating the same double extend I'll talk about in a second one thing that has been pretty annoying about this particular thing is that Because of the fact if anybody is ever using lookup factory and anybody else is not using lookup factory People expect the one the underscore lookup factory to have some relationship to the ones that they're getting in their app So they expect for example that if they have this instance of the thing they look up factory They expect that to work. So there's a lot of strange behavior that people are relying on and Uh that actually made it really hard to even just create a new api here Because we need to make sure that the new api does not break assumptions about people other people using the old api Um, this was like a two hour conversation with last face to face very sad and painful, but But as a general principle, this is how we usually handle intimate apis We try to leave the old ones around if we can and just make a new public one and then Do what we can to deprecate and remove the The original one over time as we were able to get the major add-ons to get off of it So the the tlvr of this api is instead of getting back Something that is actually the class what you get back is a pojo that has a create on it And the create returns an instance of the actual thing with the Injections applied. So basically it's opaque. You don't know what's going on. You also get the actual class So the main reason for this is that sometimes people put like static properties on it And they want to look at them or maybe they cash something on it We're probably going to make it a proxy in development mode So that people don't try to do things like actually construct it, right? So if you said new article new Factory for model article dot Or dot create or new of that thing any of those things. That's actually illegal conceptually so What we are probably going to do is we're probably going to make the article in development a proxy that only lets you Get properties off of it and any other operation like instance of new whatever is illegal General like proxies are pretty much a no-go in production So in production you can do whatever but that's a pretty we do that a lot And I think I'm actually pretty enthusiastic about using proxies more for this kind of thing to catch more kinds of mistakes Like if we don't think you should four in something we can discover that you're trying to do it Um, so the cool thing here is that once you got the factory dot create gives you back a real instance of the article Not a subclass and uh this thing like I said is very useful for grabbing static state that someone put on there An example of this is like our templates have static state and get instantiated and it's good for us to be able to do it Ember data did it for a long time This is a very boring thing Probably like probably half of you didn't don't even know that this original api existed The thing is that this operation of getting a factory is used a lot internally And like I said before if underscore local factory exists in the world It makes no matter what up well no matter what we want to do internally It requires us to follow the rules of underscore local factory I think the TLDR by the way of how we're going to deal with that is we're just going to have to actually remove the old api In order to get rid of double extend period Otherwise people can see the inconsistency But I think the intent is that we release factory four and then we do like our best evangelism effort To get people to get off of it like make them warnings really noisy Um and hope that that works on it and obviously if it doesn't work doesn't work, but I think We think that we think that this is an important thing for reducing startup costs and I think that would be good It's basically been step on penners hobby horse for like a very long time because if you look at profiles it shows up and you're like Okay, so glimmer components I have not written the rc. I'm probably going to get killed for this And you'll see momentarily why why the rc doesn't exist. This is very pretty speculative The funny thing is that it's the implementation is almost all complete in glimmer itself So like if you use standalone glimmer, there is a thing that looks pretty similar But making it interact correctly with the existing ember requires some thought and I'm like basically Writing by the seat of my pants here to To guess I need to write something up The story about glimmer components is that like a year ago we were like, oh, we have an implementation It's basically done then like me and godfrey started looking at it. We're like, oh, why is it so slow? Basically turned out that there were some fundamental things about how glimmer one was implemented that made The exact details of the implementation intrinsically slower And we had to rethink a lot of things and that led to glimmer two But that's why if you heard me talk about it like over a year ago and you're like, why is it not there yet? The answer is why we this is why we had to write glimmer two So yeah, uh One thing of note. This is I'm going to push hard for this. I don't know what exactly is going to happen um This dot adders was basically a pretty connected to the old glimmer components I think we're just like it's going to ending end up having been an aborted thing I think we're going to end up with this dot args for the actual thing This is why you should probably not have used that adders the whole time or any of the other apis that like we wrote about in blog posts, but never really talked about So, okay, so this is basically I would say pretty similar to what you're seeing right now you get like I'm assuming that we can do some stuff with esx classes I'm assuming that glimmer components is a good time to at least think about esx classes some But maybe that won't happen. Who knows um so I'll get to some of the details on the syntax in a minute, but What you're used to now I some of the important details what you're used to now is that if you want the outer element to have some configuration Like it has a class attribute whatever the actual class this thing would have class bindings attribute bindings whatever on them And they're the actual the outer wrapper is invisible like you can't you don't see it in your template I think this is a pretty uncontroversial thing about glimmer components now glimmer components won't have that dsl And instead the outer element in the component definition will be the thing the relevant the relevant Tag it will be the outer tag and the cool thing about that is that that lets you just like write classes attributes whatever as if they were regular classes and attributes and not have to think a lot about How to map the thing in your head into a dsl one of the things that's very cool about that Is that it makes it really easy to break apart bigger like static templates into little components and not have to be like Oh, and now I have copied this div over now. I need to like rewrite the whole all the attributes into This dsl that ember has given me so I think that's pretty cool. I'm pretty happy with it I'll get to these at things later. I have a pretty long aside on it, but basically At names are attributes are arguments that you got from the outside and If there's no at it means it's a property on the component So in this case there's a getter called title And it you know gives you a colon separated thing with kind of name And that's that's what the outer elements of your component will have a title and it will be mapped onto that Um, I'm speculating a little bit about our ability to do automatic tracking and getting rid of get Someday I will get back to the at stuff in a bit Otherwise it's pretty similar to the same story of what you have today, which is basically you have curlies curlies Talk about the component body. You want to put you want to have an action you create an action You can say that you would like to do it on a particular thing. You can do something with it, etc In terms of the usage you call it using angle bracket syntax That's also one of the pretty uncontroversial things Again, I'll get back to this in a minute like literally a minute But basically the idea is that names that are talking to the component are at names And the at basically the at on the inside and the at on the outside are talking about the same thing I'll I'll the the I'll give you a Spoiler about at which is it turns out that there are these things in html called attributes And you would like them to use attributes and sacks and you cannot actually make both of them work I'll go into some detail later about why that is But you actually do need to differentiate between Things that you want to mean html attributes and things that you want to mean talk to the component And this is the best that we that we came up with after a lot of effort. Um, I I'm happy with it. So Also, the at thing is a thing in regular handovers, which is helpful Uh, anyway, so the idea is bait is that parameters to ember things are at Attributes regular attributes are at our regular attribute syntax At name syntax means it's not an attribute and that basically means glimmer knows how to pass the value directly You would not want every single time you put sent an attribute to a glimmer component for it to get stringified first That would be pretty pointless and also very expensive. So This gives you a way to pass values directly and not have them show up in your dom Uh, this one is a thing that like everyone on the ember core team really likes But I think hasn't really necessarily penetrated the regular ember ecosystem. Uh, it's a thing called element modifiers It's another one of these names that you will not understand what it means if you don't know um I like to say it's just like didn't sort of element for regular elements where you don't have a component and basically the idea is that you can It's like the action helper, right? You can put stuff on it on an element and Then you can implement it looks a lot like a component and it has all the life cycle of a component and you can use the element the There's sort of an interesting phenomenon here and this became more and more obvious as we were doing fast boot Which is that there is it is actually important for there to be a strong differentiator between Attributes which can get serialized to html and sent down to the client or whatever like basically handled as simple values and proper and and arguments um Or things that deal with dom directly like the didn't start element hook that really do have to be run on the client together with the Dom that's being created and one of the this is a thing that took me a while to get persuaded of but I Pretty persuaded the nice thing about modifier syntax is that it doesn't it's not like amazing It doesn't look as pretty as an attribute But it also isn't an attribute and I think the fact that it makes it clear like this is a I think angular called like either called it directives or decorators as appropriate Having a nice syntax for doing Directive slash decorators that is not the same thing as it just looks like an attribute and you have to know I think is pretty helpful also the fact that it gives you the like the full expressive syntax of Named arguments and all that is can also be pretty helpful As you can see in like the action the difference in the action helper in ember and like what you have to do in Uh pure html dsl is pretty stark. I think it's nice that you can say something that is pretty readable So anyway, the point is you can do You can do html stuff and then in fast with this stuff just won't run, right? It won't be serialized at all It will get connected on in the client um This is just me The rsc talks about positional params and I Was like, oh, I can do a nice decorator thing there and I think something like that can work But the idea is that While it's a little bit dubious to have positional params in components because components are quite often meant to be used with angle brackets In tax for modifiers even though we want the api to be pretty similar to components It's more sensible to use positional parameters And so this is basically saying the first positional parameter become the event argument and you can Do stuff and that the nice thing about so edward did the positional params api The nice thing about it is that you can If you since you mapped a position to a name if someone wants to use the named argument syntax and write event equals Whatever that basically just works, which I think is pretty cool Okay, uh Routable components GitHub why you know troll so routable components is something we I think we announced before 2.0 and we said we're gonna do it soon Um Yeah, the reason we thought we were gonna do it soon is it was like, oh, we already have ember dot view Representing this thing all we have to do is make an ember dot component when then we're done, right? Uh Turns out no so basically the thing that's Conceptually tricky about it is that regular components have invocation syntax So you say like hey, please invoke this component with these parameters seems good And there's a lot of things like the action helper that is only implemented using handlebar syntax There's no actual javascript api for creating a action helper however It actually is somewhat important for the route to be able to Do it in javascript because the route is like it's like the model hook, right? It's basically taking Uh a bunch of inputs that are your query programs and your parameters and converting it into inputs And so We could just say oh, it's exactly the same. It's the model hook. Have a nice day. It seems fine But in fact what we really need is a way to shim the fact that at the top level There's no invoke invoker There's no like syntax So basically you can imagine that there could be some syntax that looks like this But there is no actual syntax that looks like that and and as I said It's quite important that you aren't restricted to that syntax because this is the one place where you're doing pretty javascript data Transformation heavy stuff and you for sure want to be able to write something on the top So anyway, that has been a tricky thing I think we especially because we realize we're going to change the invocation syntax, right? So we're like, oh, we're changing what components actually are It seems it seemed bad for us to ship routable components that were curly components And there was actually you can probably realize there's a pretty hard problem Which is that since there's no invocation syntax It's actually hard for us to discover that you want to use glimmer components instead of angle bracket components So that was the actual original blocker was like if the opt-in is angle bracket syntax And there's no syntax then how do you opt in to use glimmer components? We have since decided to allow opt-in via this different subclass, which I think is going to be good But at the time we were like, oh, we'll try to avoid that and it was like we have basically once we go curly We can't change it. So anyway a bunch of weird annoying stuff So yeah, the idea is uh, you'll write something like this not something like this and then Your actually the names will just be available as that names as if you had invoked it using angle brackets syntax But you have not done that you have used adders This is also pretty uncontroversial That instead will it beef up the model hook to be an attributes hook Which will allow you to have more things and the default behavior is that if you have a model hook that becomes a model Attribute, but if you but you can have other things People know that you can do this with a model hook, but I think it's pretty unintuitive and has drawbacks A cool thing by the way about using all is that like in this Situation if that all three of the requests will happen in parallel Whereas if you had written a weight three times, they would have happened in serial and you so you probably want to do that I'm assuming that I actually don't really know why rcp.all and rcp.hash are two different things I think those I think those don't need to be different. I think it's easy to detect that something is an object Okay, uh Okay, so yeah So I kind of want now that I went through a lot of what we're doing. I want to talk about the attributes and props problem Just because it's interesting. I think So basically first i'll say like every project like ember has had to deal with this problem Almost nobody has done a very good job of enumerating what the problem actually is But every ember angular and reactive all had to deal with it in some way And only the people who have worked on the problem recognize that like the square bracket and circle and round thing And class name and at in ember are all actually talking about the same problem But they are all talking about the same problem. So what is the problem? So the first of all the problem is that there are three Kinds of angle bracket things and this is more or less true in all frameworks. Um There's things that are simple elements good news good for us W3c has decided that we are going to keep those syntactically distinct which is nice Then there's things that are web components. These are syntactically distinct But they are Implemented not by the browser but by a user but not by like ember not by an ember user or angular user or whatever And then there's in all three frameworks some way of implementing components for that framework using After ember all three of us will use angle bracket syntax for that. So there's this one syntax There's a sort of interesting phenomenon here by the way, which is that the top two Have different syntax, but the same semantics. They're both html elements And the bottom two have the same syntax but different semantics, which actually makes it pretty hard to find a good Semantics for all three of those things that it works There's actually four kinds of angle bracket thingies. Um, so html element and svg element are not the same thing html elements try really really hard to reflect properties as attributes. So if you said like Title equals generally speaking the idl says like please reflect that as an attribute svg does not do that. So if you try to set a property on svg element Sorry, no, that doesn't work at all. You have to actually set the attribute Also svg attributes are case sensitive html attributes are not case sensitive Which is another weird thing So there's a bunch of weird things about how html and svg things work that are not the same So there's basically four kinds So for html elements properties and attributes are basically the same with a few exceptions Um So class becomes class name because back then you couldn't uh, it was a reserved word in javascript and they were like Can't have element dot class. Uh, same thing with four becomes html four and then all multi All multi word Attributes are lowercase in html and camel case in the property So if you if you were trying to write the max length attribute because you're you know Designer and you're writing html and you are supposed to write the property That does those things are not the same as each other Um, also for svg elements properties usually don't work at all and you have to make uh, remember to not use them Um, that actually meet that results in so, uh, there's probably some context not everyone has Uh, which is that this this is all a lot of this has to do with the fact that the solution that react uses is Just to tell you that you should use properties because basically we're talking about Not html elements, but javascript objects. So obviously properties are the way to talk about things and um, the reason I brought up svg is because there is this long-running issue that Now they have actually enumerated every single svg tag in every single svg attribute So that in their implementation of components, they can shout i see you're an svg tag I gotta do the right thing but It took them a very long time and it has to do with the fact that they are trying to tell you that The semantics are properties when in fact they're actually so for svg They more or less at the abandon ship of telling you that there are properties because it doesn't work at all But now you have one syntax which looks like an attribute that magically if it's an svg Tag or or attribute Becomes an attribute so it's very it's not easy to tell just by looking at it What the semantics of x equals y is in a react template by the way? I'm not this is none of this is meant to Bash react I think these problems are actually really hard and react did accept it like for Very good reasons a pretty good solution We actually for a long time have had a pretty similar solution to what reacted with some ergonomic tweaks But I think it's I think it doesn't work Like I said the case and sensitivity rules are different in html and svg Which again means that if you were told to write foreign capital object You have to write foreign capital object unless the Spec tells you in certain situations to do something different. It's all pretty complicated My point of view is it's just too complicated For any person to memorize the only thing that people can memorize is the thing you already have to do in html Whatever it is that you already have to do in html. That's the thing you can memorize if there are rules about If being a little different here and there. It's pretty complicated Also sometimes web component authors want you to use properties instead of attributes But there are some good news Which is that web component authors can't actually ask you to do that because the whole point of web components Is that you put them inside of somebody's static html page like some designer or some person maintaining a website and if they actually require you to use properties you cannot do it So basically all web components in practice that are plausibly written allow you to use attributes They might also have properties, but that's sort of more like the regular html structure where you can use properties or attributes both work Proper attributes are treated at strings and cores appropriately, etc So yeah, you can't really get away with it. So that's that's a constraint by the way that a lot of people bring up in this space They're basically like Well, web components really need properties. Well, it turns out it turns out you can't really get away with being a web component That has that requirement. Yes, I understand. I'm literally in the end, but I'm going to go through it I think I'm actually good on that also like ember component consumers want to put regular attributes on their components which Means that we can't just make ember components use attributes syntax to mean pass some property to the component So yeah, so you want to put regular attributes on your components But actually the ember component itself wants to give wants it to give you some values So you want to be able to say like class equals or title equals and put the class for title attribute Or r a roll whatever and but you want to also be allowed to pass values not string of five versions So there's this problem where which is that we have ember components in tax which is angle brackets and has two problems Also, like people are tired of taking pull requests to add attribute bindings to their components all the time if you're a What an author of an ember component. You probably know what this is So basically we decided that if you're writing an html template and you use attributes in tax It just means attributes. I think that's the most that's the most sensible thing That also means if you copy and paste html that is valid and put into an ember template It actually always means the same thing and I think that that's a very nice thing So basically I have no idea what this is it always means this In react if you are because of the class thing in react if you want to sit if you're an svg And you are remember svg. You're not supposed to use properties and class name is not even a prop It's not a valid property. You have to remember all I'm an svg. I have to say class equals because in svg They have remapped all the all the properties as attributes, but in html. You have to say class name. I think these things are bad so anyway In ember once we're done with all the reform that we have to do here When you say attributes in tax it always means it's an attribute no matter what forever and always it's good So what's an attribute? Basically jQuery that add or semantics. I think the most notable thing about that is that Booleans mean add or remove so a thing to remember is that in html You actually cannot express an attribute of true or false that does not exist You can write the word the string true But you cannot put true or false in there and everybody who has had to implement an api that deals with attributes That is not the dom Like jQuery has meant said that boolean means add or remove and I think that's sensible So I think ember will do that specifically for the case of booleans. I think we'll probably also have a special case for functions But generally but if you say if you put a thing in here, that's a string It will always be an attribute and always mean string At foo always means I'm talking about ember no matter what so on the invocation side You will say something like this The fact that you said at name means I'm definitely talking to an ember component I definitely do not mean the name attribute if I wanted the name attribute I say name equals The fact that there's two syntaxes is also pretty nice It allows you to say at name equals and name equals and get both the name property and also the name attribute Which might be useful on the usage side you refer to the thing that people pass you with the same at name so matches What about web components that want you to supply properties good news they can't actually get away with it What about but in addition to the fact that they can't get away with it What if you have an html element that wants you to supply properties? Well, you there's a good escape file for that called the insert element You should definitely do that if someone insists that you use an imperative api and also element modifiers are going to be Pretty good solution for more general cases Doesn't react doesn't react to the property basically works No no So like ember definitely does not want this page Definitely want to deal with that or like I showed you before that again. This is not a dig against react It's just actually hard and that's solution about properties You think it works and it was very easy to convince yourself like oh obviously a lot of people use react So it's fine What's actually happening is a lot of people use react and it is a price a lot of react people pay to use react It has not caused them to not want to use react But that doesn't actually mean that we have to do in an ember just means It's not a sufficiently large cost that react users feel like abandoning ship on mess, but I think that's uh, That's too low the bar Also, there are cases like read only we're updating the property actually fail So if you said read if you tried to bind read only to something and update it later You can't actually set that property. It's illegal in javascript. So you have to act with the attribute and React actually has a very big file with a lot of special cases The nice thing is you don't need the big file if you just say that attributes mean attributes So, yeah, I'm gonna And I'm done. Yeah Basically saying attributes and attributes Thank you