DEV Community: Alberto Cantú Gómez

How to build a search experience

Alberto Cantú Gómez — Sun, 24 Jan 2021 20:52:39 +0000

TL;DR

@elastic/search-ui separates the UI from the core search mechanics and functionality and thus allows you create any search experience using any modern framework, even plain Javascript! While the Elastic's default UI implementation is written for React apps, in this blog post I will show the Ember.js implementation using the new addon ember-search-ui. Here's the Ember.js demo.

Search experiences

Most software shares these basic requirements: some way to create, edit, or delete something (usually forms) and a way to search for them, the classic CRUD. There is an ongoing challenge to help our users / customers / clients with the best ways to find the information they need in our applications. There are many ways to create these search experiences, here are some examples:

We have the all time classic, table with filters per column.

Using a map to find locations on Airbnb

A Kanban board to list issues on Jira

Job listing sites, such as LinkedIn

Product listing on Amazon

Looking closely we can notice how all these search UIs use these:

Some kind of inputs or controls to filter/drill down search results
How the search query actually made
How the latests results look like

In the ever-growing world of open source we can find all kinds of libraries that help us build the classic table with filtering, paging, sorting and many more common functionalities, and hey, who wants to recreate them? They are amazing, battle tested, work as described and actually help us a lot in most scenarios; Still, I always found myself hitting a wall trying to improve the UX of this specific table in this particular project with some specific control to filter the results, or even reusing these controls on many different pages to maybe display the results of one differently, which often leads to rewrites or re-implementation of the internals of the library, increasing the surface area for bugs and if the application is large enough it often feels like you have to maintain two or more source codes.

This issue is even more noticeable when you move from project to project, between ecommerce sites and data-driven dashboards and more, the problem is that these libraries link the user interface with the search mechanics, wouldn't it be amazing if they were separated? so that we can implement the user interface of our choice (hopefully the best one for your users), using the same basic concepts. Enters ember-search-ui.

Ember Search UI

ember-search-ui is an ember-cli addon that uses the core package @elastic/search-ui to give us ember developers a way to create any search experience and reuse any part of it between different pages, projects and the most complex UX requirements.

It consists of 2 main concepts. Keep in mind this is not a tutorial, it's just a small MVP presentation, so please check out the complete reference

config: a simple javascript object that implements at onSearch method, this is like ember data adapter, where you would want to configure your API specifications, it is simple; takes the current state of the driver and waits for a new state, you can apply here whatever data transformation your application needs, for example, transform current filters to json-api, add auth headers and more.
```
  {
    onSearch(state: RequestState) : ResponseState,
  }
```
driver: the driver is a framework agnostic piece of state and the glue of everything, it has 3 core purposes:
1. It exposes some actions with clear API to create new searches, via driver.getActions()
2. It emits events to subscribers when there's a new state change produced by any of these actions, you can subscribe using driver.subscribeToStateChanges(this.yourCallBack)
3. It holds the current results, filters and pagination, you can access the current state using driver.getState()

With these two you can basically create any UI, ember-search-ui gives you two simple components:

<SearchProvider />: Basically an easy way to instantiate a driver in any template.


  <SearchProvider @config={{this.config}} as |driver|>
    <Table @driver={{driver}} @columns={{this.columns}} />
  </SearchProvider>

<WithSearch />: This component subscribesToChanges to any driver passed it as argument, you'd also need to provide a function @mapContextToProps that takes the current state and actions object and return the portion of the state and actions to set into the state of this component, this way we avoid whole tree re-renders, (stateAndActions) => subsetOfStateAndActions, for easy usage this addon comes with a helper map-context-to-props which receives the keys of the state or actions this component uses.

A couple of examples using the popular ember-paper for material styles.

A search input component, lets call it `<SearchBox />`

  {{!  search-box.hbs }}
  <WithSearch 
    @driver={{@driver}} 
    @mapContextToProps={{map-context-to-props 
      "searchTerm" 
      "setSearchTerm"
    }} 
  as |state|>
    <PaperInput 
      @label="Search"
      @placeholder="Start searching..."
      @value={{state.searchTerm}} 
      @onChange={{state.setSearchTerm}} 
    />
  </WithSearch>

Displaying results component, let's call it `<SearchResults />`

  {{!  search-results.hbs }}
  <WithSearch 
    @driver={{@driver}} 
    @mapContextToProps={{map-context-to-props "results"}} 
  as |state|>
    <PaperList>
      {{#each state.results as |result|}}
        <PaperItem class="md-2-line">
          <img src={{result.img}} alt={{result.name}} class="md-avatar">
          <div class="md-list-item-text">
            <h3>{{resul.name}}</h3>
            <p>{{result.price}}</p>
          </div>
        </PaperItem>
      {{/each}}
    </PaperList>
  </WithSearch>

Maybe we want to add an slider which filters down the products

Filter Slider component, lets call it `<Filters::Slider />`

  {{!  filters/slider.hbs }}
  <WithSearch 
    @driver={{@driver}} 
    @mapContextToProps={{map-context-to-props 
      "filters" 
      "addFilter" 
      "removeFilter" 
      "setFilter"
    }} 
    as |state|>
    {{#let 
      (find-by "field" @filterField state.filters) 
    as |filter|}}
      <PaperSlider 
        @min={{0}} 
        @max={{100}} 
        @value={{filter.values.firstObject}} 
        @onChange={{fn state.setFilter @filterField}} 
      />
    {{/if}}
  </WithSearch>

Wrapping it up...

<SearchProvider @config={{this.config}} as |driver|>
  <SearchBox @driver={{driver}}/>
  <Filters::Slider @driver={{driver}} @fielterField="price"/>
  <SearchResults @driver={{driver}}/>
</SearchProvider>

As we can see we defined a complete unique search experience that is decoupled of any particulars, you could add or create any new filters (even a Map like Airbnb), display the results completely in a different way, a table perhaps? the possibilities are endless.

I hope you liked the intro and it helps you to build amazing UIs for your users and helps you and your team have sanity while building these!

Please take a look at ember-search-ui. There's an example for a more deep dive on ember specifics, and ping me on twitter if I can help you with anything.

This addon is merely a port of the amazing work of @elastic/search-ui, so thanks to everyone on Elastic team for continually making these incredible open source work. Please refer to that repo for a complete reference of the APIs.

Handy Emberjs Globals for Developing

Alberto Cantú Gómez — Sat, 20 Jun 2020 18:42:41 +0000

TL;DR

Here are some handy globals you can use in your Ember.js app to debug faster, even without ember inspector

If you would like to use the addon version:

ember-handy-globals

You can also find it as gist

In this blog post you will learn how to add some nice globals to help you while developing your Ember.js app.

One of the things that makes Ember.js ecosystem a breeze is the Ember Inspector. Quite often as Ember.js devs we use it to grab the current controller, a service, the route current model or a component to debug it, even while writing this post I learned a few new things about the inspector, I've never used the Promises tab before 🤒, I love it!

But from time to time quick fixes and checks starts to feel a little bit annoying. Specially in long debugging sessions and of course if you like autosaving files in VSCode, like I do.

Also from time to time you need a few ember objects in the console to debug correctly, or build up some complex object, so having the $E reserved for a particular inspector object is not necessarily enough.

Another good reason to do so, is that sometimes you are testing your app in a browser that doesn't have ember-inspector available or installed, so this gives you a set of tools to handle this!

Here is an excellent Intro To Ember Inspector if you are not familiar 😄

Off we go, Global instance-initializer

One of the files I keep bringing from project to project, is the so called instance-initializer/globals.js

ember generate instance-initializer globals

Here I quote the Ember.js Application and Instances

Every Ember application is represented by a class that extends Application. This class is used to declare and configure the many objects that make up your app.

As your application boots, it creates an ApplicationInstance that is used to manage its stateful aspects. This instance acts as the "owner" of objects instantiated for your app.

Essentially, the Application defines your application while the ApplicationInstance manages its state.

So in this instance-initializer, we receive the application instance, which I use to create or derivate globals that keeps me productive.

//instance-initializer/globals.js

export function initialize(application) {}

export default {
  name: "globals",
  initialize,
};

First we might want to ensure we only add these while on development

//instance-initializer/globals.js

export function initialize(application) {
  let { environment } = application.resolveRegistration('config:environment')
  if ( environment !== 'production') {
  }
}

export default {
  name: "globals",
  initialize,
};

Basic useful globals

//instance-initializer/globals.js

export function initialize(application) {
  let { environment } = application.resolveRegistration('config:environment')
  if ( environment !== 'production') {
    /**
      This basically exposes the application, pretty useful because
      you can use stuff like this from the console.

      App.lookup('route:some-route').actions.doSomething();
    */
    window.App = application;

    /*
      This will gives us access to the store easily, to make fast queries or checks!

      Fast and easy:
      var s = App.store.peekRecord('some-model', 1);

      App.store.createRecord('some-model', {name: 'Alberto'})

    */
    window.App.store = application.__container__.lookup("service:store");
  }
}

export default {
  name: "globals",
  initialize,
};

After using App.lookup() directly for some time, I found too time consuming to time the type of object I was looking for

App.lookup("service:some-service");
App.lookup("route:some-route");

So I started to add a function shorcuts.

//instance-initializer/globals.js

export function initialize(application) {
  let { environment } = application.resolveRegistration('config:environment')
  if ( environment !== 'production') {

   ...//to avoid making this too long

    window.App.service = function(name) {
      return application.lookup(`service:${name}`)
    }
    // or a shortcut for every ember types.

    let objects = [
      'service',
      'controller',
      'route',
      'model'
    ];

    objects.forEach(type => {
      window.App[type] = function(name) {
        return application.lookup(`${type}:${name}`)
      }
    })
  }
}

export default {
  name: 'globals',
  initialize
}

While it's almost the same typing, first its truly easier to type, but also, the chrome console autocompletes, so a win.

App.controller("auth.projects");
App.model("some-model");
App.route("auth.projects");

And the most recent addition who actually made me write this blogpost, my ultimate gift 😅.

//instance-initializer/globals.js

export function initialize(application) {
  let { environment } = application.resolveRegistration('config:environment')
  if ( environment !== 'production') {
    class CurrentContext {
      get model() {
        return application.lookup(
          `controller:${application.lookup("service:router").currentRouteName}`
        ).model;
      }
      get controller() {
        return application.lookup(
          `controller:${application.lookup("service:router").currentRouteName}`
        );
      }
      get route() {
        return application.lookup(
          `route:${application.lookup("service:router").currentRouteName}`
        );
      }
    }


    window.App.ctx = new CurrentContext(); 
  }
}

export default {
  name: "globals",
  initialize,
};

We create this CurrentContext class just to have native getters, to avoid having to call methods. It uses the currentRouteName from Service Router to get the current model, route or controller, so this is effectively a super shortcut for quick debugging stuff!

var model = App.ctx.model; //current route model!
var controller = App.ctx.controller; //current route controller!
var route = App.ctx.route; //current route route!

What do you think about these shortcuts? Do you plan to use some of them? do you have any secret one you would like to share to the #emberjs community? Please do!

If you would like to use the addon version:

ember-handy-globals

You can also find it as gist

Understanding Ember.js Public Assets Path for Browser and Cordova 🗄

Alberto Cantú Gómez — Sun, 07 Jun 2020 17:38:17 +0000

Correction

Thanks to @neojp for his response https://twitter.com/neojp/status/1269708074387939329

I wrote this blog post without fully understanding the reasoning behind ember rewriting urls, fingerprinting and the TIL <base /> tag, the simple and pretty straightforward solution to handle urls in both environments is to just add a <base href={{rootURL}} /> in /app/index.html. I started using ember around 2.8, and I just found out what was the actual purpose of baseURL in config/environment.js and well, it got deprecated back in ember-cli 2.7, this practically changes how assets urls work in ember. Surprisingly the recommended solution is to use

fully-qualified paths or a root-relative URL.

For example

{{! Old: (with baseURL and/or <base /> tag) }}
<img src="assets/images/logo.png" />

{{! New: }}
<img src="/assets/images/logo.png" />

If you want to add the base tag, which I do recommend:

<!-- index.html -->
...
<head>
  <base href="{{rootURL}}" /> 
</head>

This means that all non fully-qualified urls will get the rootURL of your config/environment.js prefixed by the browser.

I think this is not really that well documented in Ember.js guides or Ember.js tutorial. New ember apps starts without the <base /> tag, thus won't seamlessly work in the browser and in corber, because while running in cordova you can't simply point relative paths i.e /asset/img/photo.jpg, all assets are placed elsewhere. The silver bullet is the <base /> tag.

The helper proposed in this blog post is useful if you want another way around adding the <base /> tag in your index.html because of some unexpected behaviors around it or just to follow(?) the current ember-cli blueprint... the following helper gives you the correct relative path in templates and JS regardless if you are running in cordova or the browser, you just gotta make sure this helper runs after cordova.deviceReady

// helpers/public-url
import Helper from '@ember/component/helper';
import config from 'ember-get-config';

let IS_READY = false;

export function publicUrl(url) {
  if (typeof FastBoot === 'undefined' && window.cordova && IS_READY) {
    return `${window.cordova.file.applicationDirectory}www/${config.ENV.rootURL}${url}`;
  }
  return `${config.ENV.rootURL}${url}`;
}

export default Helper.extend({
  cordovaEvents: service('ember-cordova/events'),

  deviceReadyObserver: subscribe('cordovaEvents.deviceready', 
    function(){
      IS_READY = true;
      recompute();
    })

  compute([url]){
    return publicUrl(url);
  }
});

And use it in templates like this

<img src={{public-url "assets/images/teams/{{team.short_name}}.png"}} alt="{{team.name}}'s flag" style="width: 50px;">

And in js like this

import { publicUrl } from '../helpers/public-url';
publicUrl(`assets/images/teams/${team.short_name}.png`);

Recursion in Ember.js Templates, case factorial(n)

Alberto Cantú Gómez — Fri, 01 May 2020 21:06:12 +0000

Factorial

The product of (= the result) a whole number and all the whole numbers below it

Four factorial (4 x 3 x 2 x 1) is 24

Goal

Create a Factorial component which will calculate the answer recursively using only templates and helpers.

Step 1 - How to calculate factorial using recursion

Let's first see how to solve the factorial using recursion in JS land

function factorial(number) {
  if(number === 0) return 1; //when we get to the base case it returns 1.
  return number * factorial(number-1) //Recursion, we are calling factorial again with n-1
}

factorial(3) //6

Step 2 - Factorial Component

Let's write the same, but using ember templates (this is not the final version), it's purpose is to show similarity with the js equivalent

eq is a helper to test equality {{eq "hola" "bye"}} = false

sub is a helper to subsctract something {{sub 5 1}} = 4

mult is a helper to multiply something {{mult 5 2}} = 10

You can find these helpers and more at

ember-math-helpers

ember-truth-helpers

{{! factorial.hbs}}
{{#if (eq @number 0)}}
    {{return 1}} {{! when we get the base case, it retuns 1.}}
{{else}}
    {{return 
        (mult @number <Factorial @number={{sub @number 1}} />)
  }} {{! Recursion, we're calling factorial again with n-1}}
{{/if}}

This algorithm seems correct, and conceptually this is the same as the JS equivalent, but it has some errors.

First, when you want to return something in ember templates, you use yield keyword instead of return

{{! factorial.hbs}}
{{#if (eq @number 0)}}
    {{yield 1}} {{! when we get to the base case, return 1.}}
{{else}}
    {{yield 
        (mult @number <Factorial @number={{sub @number 1}} />)
  }} {{! Recursion, we're calling factorial again with n-1}}
{{/if}}

By last, this is the difficult part where we find ourselves a bit lost, whereas it can actually yield or "return" a component

{{yield (component 'factorial' @number=(sub @number 1)}}

This component would not actually run, so the client of this code would need to do something like this.

{{#let 10 as |number|}}
  <Factorial @number={{number}} as |Factorial|>
        <Factorial />
  </Factorial>
{{/let}}

Which actually does nothing because we are never getting the answer.

Here's the solution

{{! factorial.hbs}}
{{#if (eq @number 0)}}
    {{yield 1}} {{! when we get to the base case, return 1.}}
{{else}}
    {{! Recursion, we are calling factorial component again with n-1}}
    <Factorial @number={{sub @number 1}} as |answer|> 
        {{yield (mult @number answer)}} 
    </Factorial>
{{/if}}

By yielding the multiplication of the current number times the response of another factorial(n-1) (inside the block), we just covered the recursion.

Here's the final Component "API".

{{#let 10 as |number|}}
  <Factorial @number={{number}} as |answer|>
        <h1>{{number}}! is {{answer}}</h1>
  </Factorial>
{{/let}}

Finally if we wish to visually display or render the recursive tree nicely, we could use the <ul> tag

{{! factorial.hbs}}
{{#let
  (array "red" "blue" "yellow" "orange" "pink") as |colors|
}}
  <ul style="background-color: {{object-at (mod (sub @number 1) colors.length) colors}};">
    {{#if (eq @number 0)}}
      {{yield 1}} {{! when we get to the base case, return 1.}}
    {{else}}
      {{@number}} * factorial({{sub @number 1}})
      {{! Recursion, we are calling factorial component again with n-1}}
      <Factorial @number={{sub @number 1}} as |response|> 
        {{yield (mult @number answer)}} 
      </Factorial>
    {{/if}}
  </ul>
{{/let}}

And the Ember inspector would look like this!

Here's a demo

Why using templates instead of pure JavaScript?

Ember templates rerender automatically when some value (must be a @tracked decorated property or an Ember.Object property) referenced in them, changes, this means that we could have an observed recursion. Our components tree can actually make smart decisions, so we can have a recursive logical tree that recalculates on arbitrary events, like clicking a button that might increment a property referenced by the template thus, triggering a rerender, etc. In other words, we can take advantage that ember templates already know exactly when to "rerender" as effective observer(s) of our recursion.

You can of course solve these kind of problems also by adding observers in your components js class, or some other technique, which is usually way more verbose and would need some kind of hand wiring observers via addObserver and then destroy them if the component gets destroyed.

About our use case

This short blog post is about something I learned with my colleagues today while trying to calculate a value using a recursive technique on ember templates, which we finally did not use.

Our use case was very strange and specific, we wanted a way to reduce a complex nested object (flatten an object) to create a live array, so a client could iterate on. This "live" stuff would use the templates "observavility" and automatic "rerenders" to effectively observe an external dependency, i.e. DS.Model instance, because the flattening process has logical branches based on the DS.Model properties actual values (referenced in the templates). Since any change in DS.Model would cause a complete rerender, and the performance implications were dire, we chose other path.

Auto Save en Ember Octane 💾

Alberto Cantú Gómez — Sat, 25 Apr 2020 22:12:12 +0000

Este es un blog-post para desarrolladores de JavaScript y sobre todo de Ember.js, es avanzado por lo cual supone que tienes conocimiento de JavaScript e idealmente de Ember.js.

Una nota antes de empezar

Este será el primer blog que hago en español, considero que falta mucho contenido sobre tecnología en español y específicamente de Ember.js moderno, el cual forma parte de mi día a día como desarrollador. Para no forzar traducciones cuando complican el texto, voy a dejar un glosario al final cuando considere necesario, sin embargo si tienes alguna duda siempre puedes localizarme en twitter @betocantu93

¿Qué es Ember.js?

Bueno primero no me gustaría suponer que conoces Ember.js, Ember.js es un framework de JavaScript para construir aplicaciones web robustas y escalables, sus principales atractivos son:

Baterías incluídas, un proyecto nuevo de Ember.js incluye entre muchas otras cosas:

Build pipeline (olvídate de estar configurando Rollup, Webpack o demás)
Un router
Data Layer (Ember Data, para manejar los datos en tu proyecto)
Testing
Performance

Las convenciones, permiten desarrollar un proyecto web escalable de manera ordenada y predecible, un desarrollador de Ember.js puede brincar de proyecto en proyecto sin ningún problema ya que se sentirá en casa con código muy familiar.
Addons, son como "plugins" que le puedes añadir a tu aplicación, paquetes de npm que gracias a las convenciones de Ember.js, pueden añadir código que aumente la funcionalidad de tu aplicación de manera asertiva, incremental y poderosa.

¿Quieres utilizar graphql y apollo? ember-apollo-client
¿Quieres animaciones? ember-animated
¿Quieres material design? ember-paper
¿Quieres soportar muchos lenguajes? ember-intl
¿Quieres mapas? ember-mapbox-gl

Código Libre, Ember.js es desarrollado por la comunidad alrededor del 🌍, todos pueden contribuír y no hay ninguna empresa entorpeciendo con sus intereses.
Fuerte versionamiento, Ember.js tiene un compromiso con no romper las aplicaciones de todos entre versiones ya que tiene un fuerte sistema de versionamiento y de ir removiendo código obsoleto, puedes estar seguro de que tu aplicación podrá migrar a nuevas versiones sin tener que reescribirla a através de los años.

Auto Save 💾

Pero, ¿qué es Auto Save?

Auto save es guardar un modelo o documento cada vez que ciertos eventos sucedan, esto tiene dos beneficios importantes

Mejora la experiencia de usuario al no tener que estar dando clic en 💾 a cada cambio en documentos o formularios grandes
Puede evitar el miedo de perder la información

Basta de intros, empecemos a ver código.

Nuestro modelo `Person`

import Model, { attr } from '@ember-data/model';

export default class PersonModel extends Model {
  @attr firstName;
  @attr lastName;
  @attr birthday;
}

Primero que nada necesitamos un componente para nuestro formulario básico tradicional y lo iremos poco a poco mejorando, en este caso estaré utilizando ember-paper por facilidad

{{! components/edit-person/index.hbs }}
<PaperForm @onSubmit={{@onSubmit}} as |Form|>
    <Form.input @onChange={{fn (mut @person.firstName)}} @value={{@person.firstName}} />
    <Form.input @onChange={{fn (mut @person.lastName)}} @value={{@person.lastName}} />
    <Form.input @onChange={{fn (mut @person.birthday)}} @value={{@person.birthday}} />

    <Form.on-submit>
    Guardar
    </Form.on-submit>
</PaperForm>

Bueno y ¿cómo lo uso? Muy fácil, hay que suponer que el this.save es una función en el controller que se encarga de hacer this.model.save

{{! templates/person.hbs}}
<EditPerson 
    @person={{this.model}} 
    @onSubmit={{this.save}}
/>

Ahora la primer cosa que puede mejorar un poco para hacer más fácil el trabajo con estas tribialidades como crear un controller para definir una acción this.save con this.model.save, utilizando ember-composable-helpers puedes simplemente utilizar el helper de invoke

{{! templates/person.hbs}}
<EditPerson 
    @person={{this.model}} 
    @onSubmit={{invoke "save" this.model}}
/>

Ahora, ¿cómo se vería nuestro componente de EditPerson si reemplazamos el botón de guardar por una función de autosave?

{{! components/edit-person/index.hbs }}
<PaperForm as |Form|>
    <Form.input 
        @onChange={{fn (mut @person.firstName)}} 
        @value={{@person.firstName}}
        @onBlur={{@autoSave}}
    />
    <Form.input 
        @onChange={{fn (mut @person.lastName)}} 
        @value={{@person.lastName}} 
        @onBlur={{@autoSave}}
  />
    <Form.input 
        @onChange={{fn (mut @person.birthday)}} 
        @value={{@person.birthday}}
        @onBlur={{@autoSave}}
   />
</PaperForm>

De esta manera, cuando el usuario salga del input (onBlur) se estará ejecutando una función de autoSave, esto deja al que invoca el componente la decisión de cómo hacer el autosave.

{{! templates/person.hbs}}
<EditPerson @person={{this.model}} @autoSave={{invoke "save" this.model}}/>

Esto funciona, pero qué tal si el usuario utilizara [ Tab ] para moverse por tu forma, estarías haciendo muchos {{invoke "save" this.model}} probablemente innecesarios, para eso vamos a introducir un nuevo concepto

El Componente AutoSave

Este componente nos ayudará a encapsular lógica de auto save y que vamos a poder "inyectarla" en cualquier template.

// components/auto-save/index.js
import GlimmerComponent from '@glimmer/component';
import { task, timeout } from 'ember-concurrency';

export default class AutoSaveComponent extends GlimmerComponent {  
  @(task(function(){
    yield timeout(500);
    try {
      return yield this.args.model.save();
    } finally {
      //Si hay un error, de permisos, por ejemplo.
      this.args.model.rollbackAttributes();
      //manera fácil de no tener que guardar track de el dirtinessde las relaciones
      this.args.model.reload();
    }
  }).keepLatest()) autoSaveTask;
}

Para evitar que nuestra función se dispare de maneras no controladas, podemos utilizar el addon ember-concurrency que de una manera muy declarativa nos deja implementar el patrón de debouncing, que obliga a que una función no sea llamada otra vez hasta que cierto tiempo haya pasado sin ser llamada otra vez, algo así como "Ejecuta esta función, solo si 500 milisegundos han pasado sin que se haya vuelto a llamar".

¿Pero cómo utilizar este componente? Necesitamos primero hacer yield de nuestra task en nuestro template

{{! components/auto-save/index.hbs }}
{{yield (perform this.autoSaveTask)}}

Finalmente, podemos utilizarlo con facilidad.

<AutoSave @model={{this.model}} as |autoSave|>
    <EditPerson @person={{this.model}} @autoSave={{autoSave}} />
</AutoSave>

Me gusta este patrón en el cual abstraemos una funcionalidad a un componente, de esa manera podemos reutilizar código sin tener que utilizar Mixins, son como Mixins pero en "Render", interesante.

Todavía tenemos algunos casos extremos a resolver

Con el diseño actual, podemos estar ejecutando guardar aún y cuando no es necesario, ya que puede que no haya cambiado el valor, por lo tanto innecesario.
ember-concurrency cancela todas las task cuando el objeto en el que viven es destruído. Como estamos manejando la creación de la task en un componente, hay un caso extremo en donde el usuario podría hacer cambios en el modelo y cambiarse de ruta por el algún botón de tu UI, mientras aún se está ejectuando la estrategia de debounce (esperando los 500ms) en la task, por ende puede ser que no se complete y guarde nuestro modelo lo que representa posible pérdida de información y es intolerable.

Para resolver el punto 1, podemos agregar un check antes del debouncing

// components/auto-save/index.js
import GlimmerComponent from '@glimmer/component';
import { task, timeout } from 'ember-concurrency';

export default class AutoSaveComponent extends GlimmerComponent {  
    /*
        @param {Boolean} checkIfDirtyAttributes Verificar si el modelo tiene cambios 
    */
  @(task(function(checkIfDirtyAttributes = true){
    if(
      checkIfDirtyAttributes && 
      this.args.model.get('hasDirtyAttributes')
    ) { 
      yield timeout(500);
      try {
        return yield this.args.model.save();
      } finally {
        //Si hay un error, de permisos, por ejemplo.
        this.args.model.rollbackAttributes();
        //manera fácil de no tener que guardar track de el dirtinessde las relaciones
        this.args.model.reload();
      }
    }
  }).keepLatest()) autoSaveTask;
}

Ember Data lleva un registro en todo momento si el atributo de un modelo cambió, pero no de si sus relaciones han cambiado, entonces si quieres guardar por que se cambió una relación, puedes ignorar los atributos, @onChange={{fn @autoSave false}}

Para resolver el punto 2, podemos mover el task del componente al modelo en sí.

import Model, { attr } from '@ember-data/model';
import { task, timeout } from 'ember-concurrency';

export default class PersonModel extends Model {
  @attr firstName;
  @attr lastName;
  @attr birthday;

  /*
        @param {Boolean} shouldRun puede o no ejecutarse?
    */
  @(task(function(shouldRun = function(){return true;}, checkIfDirtyAttributes = true){
    shouldRun = typeOf(shouldRun) === 'function' ? shouldRun(this) : shouldRun;

    if(!shouldRun) { return; }
    if(checkIfDirtyAttributes && !this.get('hasDirtyAttributes')) { return; }

    yield timeout(500);
    try {
      return yield this.save();
    } finally {
      //Si hay un error, de permisos, por ejemplo.
      this.rollbackAttributes();
      //manera fácil de no tener que guardar track de el dirtinessde las relaciones
      this.reload();
    }

  }).keepLatest()) autoSaveTask;
}

Como podemos ver, reemplazamos el this.args.model por this, porque ahora esta task vive en un modelo en sí, además para hacerla un poco más flexible y reutilizable, permitimos que nos envién una función que retorne un boolean o un boolean en sí para saber si correr o no el task.

Tenemos que actualizar nuestro componente AutoSave

// components/auto-save/index.js
import GlimmerComponent from '@glimmer/component';
import { task, timeout } from 'ember-concurrency';

export default class AutoSaveComponent extends GlimmerComponent {  
    get shouldRun() {
    /*
        Podríamos tener aquí cualquier validación extra, 
        por ejemplo, permisos de ember-can
    */
    return true;
  }
}

{{! components/auto-save/index.hbs }}
{{yield (perform @model.autoSaveTask this.shouldRun)}}

Al final, nuestro componente <AutoSave /> se puede decir que es un helper / mixin que funciona como middleware para ayudarnos a ejecutar la task en nuestro modelo.

Es un patrón algo complejo, pero permite agregar agregar fácil funcionalidad de autoSave a cualquier formulario de manera sencilla, ideal para aplicaciones modernas.

DEV Community: Alberto Cantú Gómez

How to build a search experience

TL;DR

Search experiences

We have the all time classic, table with filters per column.

Using a map to find locations on Airbnb

A Kanban board to list issues on Jira

Job listing sites, such as LinkedIn

Product listing on Amazon

Ember Search UI

A search input component, lets call it <SearchBox />

Displaying results component, let's call it <SearchResults />

Filter Slider component, lets call it <Filters::Slider />

Handy Emberjs Globals for Developing

TL;DR

Off we go, Global instance-initializer

First we might want to ensure we only add these while on development

Basic useful globals

Understanding Ember.js Public Assets Path for Browser and Cordova 🗄

Correction

Recursion in Ember.js Templates, case factorial(n)

Factorial

Goal

Step 1 - How to calculate factorial using recursion

Step 2 - Factorial Component

Here's a demo

Why using templates instead of pure JavaScript?

About our use case

Auto Save en Ember Octane 💾

Una nota antes de empezar

¿Qué es Ember.js?

Auto Save 💾

Pero, ¿qué es Auto Save?

Nuestro modelo Person

El Componente AutoSave

A search input component, lets call it `<SearchBox />`

Displaying results component, let's call it `<SearchResults />`

Filter Slider component, lets call it `<Filters::Slider />`

Nuestro modelo `Person`