Functional attribute values

[ngsilverman]

Wondering if something like this would be useful:

val style = myViewStyle {
    backgroundRes { myView ->
        if (myView.something()) {
            R.drawable.something_background
        } else {
            R.drawable.another_background
        }
    }
}

Could this become a reactive pattern? For example a single style could differ depending on whether the view is enabled or not, all we'd need is a way to know when to refresh/re-apply the style.

Note: we wouldn't want to whole style to have access to the view instance to avoid differing attribute sets depending on conditions.

[elihart]

nifty idea. One potential issue I think is losing the ability to do equals/hashcode. Epoxy has the same issue with click listeners and it can be quite a headache to deal with.

[ngsilverman]

Good point. We could still compute a view specific hashcode, and if it differs from that of the previously applied style before the view is drawn again the style could be reapplied (the last style applied to each view would have to be saved somewhere for this to work, possibly as a tag).

[elihart]

epoxy already saves the last style applies as a tag to avoid reapplying

if (!Objects.equals(style, that.style)) {
      HeaderViewStyleApplier styleApplier = new HeaderViewStyleApplier(object);
      styleApplier.apply(style);
      object.setTag(com.airbnb.viewmodeladapter.R.id.epoxy_saved_view_style, style);
    }

it would be nice if paris actually provided a util for that so epoxy didn't have to do it itself

[ngsilverman]

I'm wondering if Paris could assign a unique id to all the linked styles and use it to compare them. It would be more efficient than using equals like Epoxy does, and it would make it possible to compare instances of functional styles.

[elihart]

that's a cool idea. maybe it could be even simpler and for linked styles we can just use reference equality?

would it be possible to only do that for linked styles though?

[ngsilverman]

@elihart reference equality wouldn't work for methods (or functions) annotated with @Style.

The unique id could be a string signature of the field/method/property/function:

// field
com.myapp.customviews.MyView#MY_STYLE

// method
com.myapp.customviews.MyView#myStyle()

// companion property
com.myapp.customviews.MyView.MY_STYLE

// class function
com.myapp.customviews.MyView.myStyle()

// lone property
com.myapp.customviews.MY_STYLE

// lone function
com.myapp.customviews.myStyle()

What do you mean by would it be possible to only do that for linked styles?

[elihart]

it would be kind of nice to remove support for methods annotated with @Style, and only allow Style objects or ints. That would simplify options and mean that all linked styles are constants

What do you mean by would it be possible to only do that for linked styles? - I guess equals will already have a === check so we wouldn't have to do that manually, but if linked styled were always constants then we could leverage that better

[ngsilverman]

I'm concerned about styles with large drawables that we wouldn't want instantiated unless they're in use. 😔 Or just large styles in general.