should configure be a connector?

Right now configure is a widget which doesn’t render anything, just like analytics.

PRO:

• easier when we split up core and widgets
• other libraries only need to handle connectors (not widgetFactories)

CON:

• this might imply there’s a value in multiple “kinds” of configure
• we might need to handle refine

[iam4x]

After working with the Configure widget, in order to have it integrated in the angular-instantsearch library I’ll add my +1 to this issue.

Also, @bobylito I think we should use the renderFn if any provided to the widget. I can see a widget with a debug: option where it prints on the page the configure search parameters applied like this:

<pre>
{
	hitsPerPage: 3,
	page: 1
}
</pre>

Also I think we should handle refine function if you want to update the searchParameters applied by Configure on the fly.

[bobylito]

Things to consider also:

• a connector for configure (and for analytics) would be artificial because the render will not be used
• in terms of semantic of the API, the connector is for widget that can be rendered. Implementing the configure as a connector, would change the semantic.

We are the implementors of the libraries so it’s our burden to do the complex stuff so if having configure as widget is only painful for us, then it should not be done if it’s easier for our users to understand as it is. From the pro / con list you made I see difficulties for users to understand the widget / connector, and a burden that we can handle (not too complex).