• README.md
  • name of component
  • example of usage
• package.json
  • name
  • description
  • git repo link (with path)
  • specific dependencies? (no * maybe)
• tests

We should keep examples inside the monorepo.

That way we can easily test the examples while developing new features.

The best would be to prefix all examples with "example".

An other approach would be to use JSFiddle, like here: https://vuejs.org/v2/examples/index.html

The worst experience is to have to much default styles part of the components.

Even the simple fact as putting in bold an active refinement can have undesired effects when use in a CSS framework context.

Let's make sure we dissociate styles from the components. All of them.

IMO opinion it would be a good idea to extract all widgets from this repository.

PROS:

• Show users how easy it is to create custom widgets
• Only import the widgets and their sub-dependencies
• Cleanup the exports

CONS:

• Needs to npm install widgets 1 by 1 (maybe we could create a vue-algolia-search-widgets bundle) which includes commonly used widgets

We have currently chosen to respect the DOM.

We must now ensure that it is still easy to integrate the components with existing frameworks like Bootstrap.

If it is not simple, we will need to consider refactoring some bits.

clearsQuery: bool, default false

That way it's the same as the other InstantSearch implementations.

As a user of a UI library, I will want to integrate the components with existing styles.

We should try to come up with an easy solution that allows us to easily be compatible with those.

• http://getbootstrap.com/css/
• http://foundation.zurb.com/
• https://getmdl.io/
• http://bulma.io/

Maybe this can be solved by only overriding classes. That would be ideal.
Also if this could be prepared at the highest level it would be perfect. Providing a specific build per framework that only overrides all the default classes of all components.

One SearchFacet

We should replace highlighting tags with something different than the replace method in highlighting and snippetting components.

Given we are moving away from a "form elements only" approach, and that the state is already hold by the Store, there is no need to name the different form elements.

It just adds more entropy to the current code.

• allow JSX support
• allow running tests on es6 files (leveraging babel vue plugin)
• same config between jest tests and actual builds

V2.1.0 comes with some great improvements when it comes to re-usability.

We should use:

• Filters in v-bind
• Scoped slots instead of passing components (for the hit template for example)
• See more: https://github.com/vuejs/vue/releases/tag/v2.1.0

The best would be to try out an autocomplete-like experience.

For the record, there is mainly one scenario that we want to cover for now:

• 1 search input
• Results from different indices

We should keep prefix for HTML elements but not for ES6 exports

build a POC of what URL sync could look like.
It will remain a user concern though.

build is usually used like dist (and thus often ignored in editors), How are other projects calling a directory with rollup configs?

Tooling:

Choose an easy to use tool for the docs, maybe just gitbook as a starter.

Navigation:

• Getting Started
  • Introduction (What is this lib)
  • Installation
    • Compatibility Note
    • Release Notes
    • Direct <script> Include
    • CDN
    • NPM / YARN
  • Components
    • SearchStore
    • etc

Component:

For each component, we need to document:

Algolia index configuration requirement

• If the component works only with some index settings, we need to explain those at the beginning
• example: attributes for faceting / attributesToHighlight etc

Basic declarative example (html)

• only show required props by default
• not slots if not required

Props

• Name
• Possible values
• Default value
• Description

Slots

• Name
• Scoped (yes/no)
• Props
• Description

Classnames

• name
• modifiers (--disabled/--active/--first/etc)
• description?

Question thread?

• Add an interactive comment thread to every page so that users can ask questions

I think best would be to have a common API for all components.
User should be able to provide classes to override, i.e.

<ais-pagination :classes="{
  'ais-pagination': 'pagination',
  'ais-pagination__item': 'page',
  'ais-pagination__item--active': 'active',
}" />

Specs:

• Should only override provided classes and keep others
• Should allow by design to be overloaded on all components (idea being that user can provide all his classes per component without bloating the actual DOM)

Not sure where this should be handled.

WDYT @Haroenv

Given the "provided" values will be "reactive" in a future release, we should not rely on direct mutations of the store.

That means we will need to probably use mutator functions or something of that kind.

algolia-search-store/src/index.js#L55

Something like this will probably work

import {version} from '../package.json';

//...
this._helper.getClient().addAlgoliaAgent(`Store (${version})`)
//...

Now easy to setup thanks to NPM coupling

Rendering them with a disabled attribute, instead of not at all will allow users to stay with their mouse on the same place, while now other components disappearing or changing height makes that hard.

It looks like I overlooked the "setter" capability of computed props: https://vuejs.org/v2/guide/computed.html#Computed-Setter

Let's check if we can use this somewhere.

Find the best way to implement this.

• Filter?
• Functional component?
• Up to the user?
• XSS protection?

Currently, only few parameters are supported by the store.
We should support all of them.

Conform with existing IS implems for most of the components.

Keep "results" and "navigationTree".

Use the same prefix everywhere (to be defined):

• ais
• alg
• algolia

To be able to lazy load results, we need to keep a computed hits value inside the searchResults widget

Radios feels a bit weird here, probably needs to be challenged a bit more and see how intgrating something like Bootstrap works out would help.

We still have places where we talk about hits (mainly in the search results component).

We should either go full-in for hits or go with results.

I know that we both chose to name it Results when we first used Algolia, but if we use that naming, we need to ensure "hits" is never used anywhere.

cc @Haroenv

Also "hits" is shorter than "results".

If we go for results we need to:

• Convert classes that contain hits
• Expose results instead of hits in the search results slot
• Convert nbHits to totalResults in the SearchStore
• Convert hitsPerPage to resultsPerPage in the SearchStore (setter & getter)
• Convert hits to results in the SearchStore
• Update all components to rely on the new naming

Ideally, there should be a default input with "clear button" + magnifying lense.

We need to see where this would fit.

We should be able to do:

<ais-store :store="store">

• Find the most used autocomplete library in Vue.js (https://www.npmjs.com/package/vue2-autocomplete-js)
• It would be nice it supports multi index
• Implement a bridge