<![CDATA[More Than Code]]>https://ilyaradchenko.comRSS for NodeMon, 14 Sep 2026 08:40:22 GMTWed, 13 Nov 2024 00:00:00 GMT<![CDATA[Build on the URL]]>https://ilyaradchenko.com/users/knownasilya/notes/cm37ckj6d0001lfpd8hwxwnq2users/knownasilya/notes/cm37ckj6d0001lfpd8hwxwnq2Wed, 13 Nov 2024 00:00:00 GMT<![CDATA[When Components Aren't Enough]]> ``` Which will focus the first non-disabled input that it finds (from [ember-autofocus-modifier](https://github.com/qonto/ember-autofocus-modifier)). ```handlebars
Some content here
``` Which will scroll to the element once it's in the DOM, and is super easy to implement: ```js // /app/modifiers/scroll-to.js import { modifier } from "ember-modifier"; export default modifier((element) => { element.scrollIntoView({ behavior: "smooth", }); }); ``` There is also the `ref` modifier from [ember-ref-modifier](https://www.npmjs.com/package/ember-ref-modifier) which gives you access to the element: ```handlebars {{this.button.dataset.name}} >> "foo" ``` Along with `{{on-click-outside}}` from [ember-click-outside](https://github.com/zeppelin/ember-click-outside). ```handlebars
Your HTML...
``` ## Why Are Element Modifiers Useful? Mainly because you can do things like: ```handlebars {{#if this.isEditorVisible}}
{{/if}} ``` Which handles the setup and teardown of the element, so if `isEditorVisible` turns `false` the editor initialized on our element will be properly cleaned up. This is important because the new Glimmer Components allow multiple top-level elements without any kind of fragment syntax. > Note: I'm using [ember-render-modifiers](https://github.com/emberjs/ember-render-modifiers) in the above example. But you could create a modifier to encapsulate both the setup and teardown so reusability is easier.]]>https://ilyaradchenko.com/users/knownasilya/notes/cltlv6sq2000vn3bbdhe2ygmsusers/knownasilya/notes/cltlv6sq2000vn3bbdhe2ygmsSun, 10 Mar 2024 18:45:08 GMT<![CDATA[Ember's Nested Routes and URLs Explored]]>https://ilyaradchenko.com/users/knownasilya/notes/cltlv5lep000tn3bbgg3zo0v9users/knownasilya/notes/cltlv5lep000tn3bbgg3zo0v9Sun, 10 Mar 2024 18:44:12 GMT<![CDATA[Sharing A Parent Model Across Route Boundaries]]> {{outlet}} ``` Now in our `dashboard.blog.post.edit` template we can use this blog model by using a helper: `{{consume-context 'blog'}}`: ```handlebars {{#let (consume-context 'blog') as |blog|}} {{! work with blog here }} {{/let}} ``` And if we wanted to access it in a controller or a component, it would be as simple as injecting the value: ```javascript import Component from '@glimmer/component'; import { inject as context } from '@alexlafroscia/ember-context'; export default class PostEditor extends Component { @context('blog') blog; } ```]]>https://ilyaradchenko.com/users/knownasilya/notes/cltlv39bn000nn3bb7stzbanmusers/knownasilya/notes/cltlv39bn000nn3bb7stzbanmSun, 10 Mar 2024 18:42:23 GMT<![CDATA[Data Down, Actions Up]]> element, and the fact that only
  • elements are appropriate as children. If we want the same type of behavior, then we have to compose our components. Just like we compose regular HTML elements, we can do the same with components. ```handlebars {{#user-list users=model sortBy='name' as |user|}} {{user-card user=user}} {{/user-list}} ``` Component Blocks Components can be used in two forms, just like regular HTML elements. Inline Form ```handlebars {{user-list users=model}} ``` Block Form ```handlebars {{#user-list users=model}} {{!-- custom template here --}} {{/user-list}} ``` To compose components, we must use the block form, but we must also be able to distinguish from within our component which form the user is implementing. This can be done with the template property. ```handlebars {{#if template}} {{yield}} {{else}}

    No Template Specified

    {{/if}} ``` We can check if template is truthy, and if it is that means that the user specified a custom template. Well, once we have a template, we probably want to use that in our component, and that's exactly what {{yield}} does. This helper can be used once, or many times. You can make your component into a type of
      element, that is a list that will repeat n times. Like the following example, where we can output a custom summary. ```handlebars {{#each posts as |post|}}

      {{post.title}}

      {{yield}}

      {{/each}} ``` Which can be used like so: ```handlebars {{#post-list posts=model}} Greatest post ever! {{/post-list}} ``` And will result in the following HTML: ```html

      Tomster goes to town

      Greatest post ever!

      Tomster on vacation

      Greatest post ever!

      ``` But what use is it to just output the same thing over and over? Don't we want to customize our posts, and display the right content? Sure we do. Lets explore the {{yield}} helper a bit. Data Down To accomplish composability beyond just simple templates, we need to pass context to those templates. This can be done with the `{{yield}}` helper. The `{{yield}}` defines where the template we defined inside our component block will yield in the component's layout, as we saw in the previous section. Apart from that, the yield helper also allows us to send data down, providing a context for the templates. ```handlebars {{yield}} {{yield "hello"}} {{yield item}} {{yield this "bye"}} ``` By default yield does not send any context, but you can provide an arbitrary number of arguments. Once you are sending data down, the child components need to consume that data. We can do this with the as operator. Let's take {{yield user "My Item"}} as an example: ```handlebars {{#user-list users=model as |user title|}}

      {{title}}

      {{user-card user=user}} {{/user-list}} ``` Now `{{user-card}}` has access to the current user, which would change if `{{user-list}}` placed it's yield helper inside an each block. This opens up the possibility to use the `{{component}}` helper for different templates, for example: ```handlebars

      Profile

      {{yield "user-avatar" user}} {{yield "user-contact" user}} {{#user-profile user=model as |section user|}} {{component section user=user}} {{/user-profile}} ``` With the `{{component}}` helper, we can bind our context to names of components dynamically, which in this case means that we can customize the user profile with custom components bound to the relevant data. This means we can have multiple extension points in our components, making them much more versatile. Actions Up Now that we can send data down, we probably want to manipulate that data via some user interaction, like changing a user's avatar, or whatever it is you're doing. We can accomplish this by using actions. Actions are great, but for actions to work in the right context, we must use the targetObject property to specify where we want the action to go. Before we can specify the targetObject property on our "acting" component, we need to expose that target as the context. ```handlebars {{yield this}} ``` The targetObject is the component that you want to handle the action, in this case it's the parent component. ```handlebars {{#user-profile user=model as |profile|}} {{user-avatar change="updateAvatar" targetObject=profile}} {{/user-profile}} ``` Since profile is the instance of the {{user-profile}} component, that means it can accept the "updateAvatar" action request. The action must be defined on the user profile component instance. Here's a mash-up of the possible scenarios with actions: ```handlebars {{#full-post post=model as |fullPost|}} {{post-like like="like" targetObject=fullPost}} {{post-subscribe subscribe="subscribe" targetObject=fullPost}} {{comment-box submit="addComment" targetObject=post viewName="commentBox"}} {{/full-post}} ``` Note: When using `{{action}}` helpers, instead of a component, you need to specify target instead of targetObject. Also, when working with actions and sibling components, use viewName to "export" the sibling component instance as a possible target.]]>https://ilyaradchenko.com/users/knownasilya/notes/cltluzcna000dn3bbsbk7cyvvusers/knownasilya/notes/cltluzcna000dn3bbsbk7cyvvSun, 10 Mar 2024 18:39:21 GMT