Bind a setting object vs define many attributes

My question is about custom element design.

Suppose this custom element:

<abt-pagination total-pages="3" selected-page="1" visible-pages="3" boundary-links="true" prev-text='' next-text='' first-text='' last-text='' prev-icon='fa fa-chevron-left' next-icon='fa fa-chevron-right' first-icon='fa fa-backward' last-icon='fa fa-forward'></abt-pagination>

It has many attributes so I want to know what is the best practice for this? Having many attributes or a setting object like this: (Maybe with a corrisponding typescript interface)

var options = {
	'total-pages': 3,
	'selected-page': 1,
	'visible-pages': 3,
	'boundary-links': true,
	'prev-text': '',
	'next-text': '',
	'first-text': '',
	'last-text': '',
	'prev-icon': 'fa fa-chevron-left',
	'next-icon': 'fa fa-chevron-right',
	'first-icon': 'fa fa-backward',
	'last-icon': 'fa fa-forward'
}
<abt-pagination setting.bind='options' ></abt-pagination>

Please guide me
Thanks.

I feel that for a very configurable element, you would probably want support two ways of passing configs: batched and individual, so that in the usage that is too customized, it’s better to be batched instead of individually configured.

When there are just few simple stuff:

<abt-pagination
  total-pages.bind="total"
  selected-page.bind="selectedPage"></abt-pagination>

When there are loaded of settings

<abt-pagination
  configs.bind="paginationSettings"></abt-pagination>

The hard part of doing configs.bind is how it should be merged / observed for changes. For the changes of the whole configs object, it’s simple and straightforward with a configsChanged(). For properties inside that config object, probably you may want to setup some dirty checking via setInterval, or create a simple rule that dynamically added properties won’t be observed. Pass in a whole new object instead.

1 Like

Instead of setInterval use the BindingEngine (see its doc for info). You can bind to a property change, collection change etc.

the other recommendation is you should normalize the code path. If you are going to expose config AND bindable props then updates to one should internally set the other. That kind of complicates things a bit.

The other thing to consider is if you have smart defaults, how much does one really need to set all 12 properties? The icons you already have what you think is a smart default. next/previous text can likely have a smart default or (empty if that is what you expect)

3 Likes

This will work if you use the binding engine to observe all configurable properties in advance, regardless they are in the config object or not. It is more appropriate if intruding the external object is ok.

1 Like