Working around "Avoid leaking state in ember objects" ESLint rule

@samselikoff wrote:

I often write components that use Objects or Arrays as configuration:

import Component from '@ember/component';
import { Styled, group } from 'ember-cli-ui-components';

export default Component.extend(Styled, {

  styles: {
    base: 'p-3 text-4 border-solid border-l-4 leading-normal',
    defaultStyle: 'info margined',

    types: group({
      info: 'bg-washed-blue border-blue text-dark-blue',
      error: 'bg-washed-red border-red text-dark-red',
      success: 'bg-washed-green border-green text-dark-green',
      warning: 'bg-light-yellow border-gold text-black-80'
    }),

    margins: group({
      margined: 'mb-4',
      marginless: ''
    }),
  }

});

In Ember 3.1 I’m getting hit with the new ESlint rule about “Avoiding leaking state in ember objects”.

I understand I can set properties in init(), but doing that drastically hampers the ergonomics of these sorts of APIs – so much so that I noticed Ember’s own properties that use this pattern are ignored by the rule. (And for good reason! I’d hate to define actions in an init method…)

My question is, is there a path forward here for these types of APIs, which have been laid out by Ember itself and I’m sure are used heavily by other Ember developers? I believe static class fields might be the answer? In the mean time, what are some things other folks are doing to work around this rule? And if everyone is ignoring it, should it be enabled by default?

Posts: 11

Participants: 7

Read full topic