maverick/flex-template-web
1
0
Fork 0
mirror of https://github.com/kingomarnajjar/flex-template-web.git synced 2026-07-26 06:47:17 +10:00
Code Issues Projects Releases Packages Wiki Activity Actions

yarn run format-docs

Browse source
This commit is contained in:
Vesa Luusua 2018-05-02 20:06:47 +03:00
parent 69a17d7452
commit 1e95444ccb
2 changed files with 20 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/extended-data.md
View file

@ -22,7 +22,7 @@ presented to the customer after a booking has been confirmed.
## Data schema and searched
Extended data works out of the box without any prior configuration to the marketplace. Public and
Extended data works out of the box without any prior configuration to the marketplace. Public and
protected data can be added to listings just by passing it in the create/update request to the API.
However, optionally a _data schema_ can be defined for an extended data key. The data schema allows
that extended data attribute to be used as a search parameter in some API endpoints, like in the
@ -31,7 +31,7 @@ listings query endpoint. Contact Sharetribe team if you need to add a schema to
## Extended data in Flex template app
The Flex web template uses extended data by default with listing and user resources. In case of the
listings, category and amenities information is stored in the `publicData` attribute. For the
users, phone number is stored in the `protectedData` attribute. As for indexed data, the template app
listings, category and amenities information is stored in the `publicData` attribute. For the users,
phone number is stored in the `protectedData` attribute. As for indexed data, the template app
relies on data schemas for categories and amenities to be configured for the marketplace in the API
as those values are used as filters in the listing search.

33
docs/search-filters.md
View file

@ -25,15 +25,16 @@ desktop search view.
Next we'll guide you through the steps of adding a _capacity_ filter to the marketplace.
First step for adding a new filter is to make sure that the data being used for filtering is saved
in the listing's `publicData` attribute. On how to achieve this, please refer to the [documentation
on extending the listing data model](./extend-listing.md). Another aspect in search filters is that
the public data needs to be indexed in the API. This is currently achieved with a manual operation
done by the Sharetribe support. Once a public data attribute is added to the listings and the data
attribute is indexed, the listing searches can be filtered by that attribute by adding a query
parameter that consists of a preceding "pub\_" and the attribute name, so for the _capacity_
attribute the parameter would be "pub_capacity".
in the listing's `publicData` attribute. On how to achieve this, please refer to the
[documentation on extending the listing data model](./extend-listing.md). Another aspect in search
filters is that the public data needs to be indexed in the API. This is currently achieved with a
manual operation done by the Sharetribe support. Once a public data attribute is added to the
listings and the data attribute is indexed, the listing searches can be filtered by that attribute
by adding a query parameter that consists of a preceding "pub\_" and the attribute name, so for the
_capacity_ attribute the parameter would be "pub_capacity".
Further reading on public data can be found in the [extended data documentation](./extended-data.md).
Further reading on public data can be found in the
[extended data documentation](./extended-data.md).
### Common changes
@ -58,8 +59,7 @@ export const capacityOptions = [
];
```
A few changes need to be made to the `SearchPage` container in order to get the filters to
work.
A few changes need to be made to the `SearchPage` container in order to get the filters to work.
`SearchPage` needs the filter options. One handy way is to add the options as a prop to the
component and then set `defaultProps` value from `config.custom` (contains the
@ -102,8 +102,8 @@ filters() {
Final thing to do in `SearchPage` is to pass the filters configuration on to the components that
take care of rendering the filters. This is achieved by `primaryFilters` and `secondaryFilters`
props that are passed to `MainPanel`. The configurations are passed as an object in the same form
as the configuration object in `filters`.
props that are passed to `MainPanel`. The configurations are passed as an object in the same form as
the configuration object in `filters`.
```js
<MainPanel
@ -123,9 +123,9 @@ passed as props to the components that render the filters: `SearchFilters`, `Sea
`SearchFiltersMobile` .The difference between filters passed as primary and secondary varies in
mobile and desktop views:
* __Desktop:__ Primary filters are shown in the top of the search view, secondary filters are
rendered in a distinct panel that opens on top of search results.
* __Mobile:__ Both primary and secondary filters are rendered in the same modal.
* **Desktop:** Primary filters are shown in the top of the search view, secondary filters are
rendered in a distinct panel that opens on top of search results.
* **Mobile:** Both primary and secondary filters are rendered in the same modal.
### Desktop filters
@ -163,7 +163,8 @@ The mobile view uses the same `SelectSingleFilterPlain` and `SelectMultipleFilte
as the filter panel. In this case the filter components are declared in `SearchFiltersMobile`. The
following steps are required to add a mobile filter:
* declare a prop with the same name that you added the filter config to `primaryFilters` or `secondaryFilters`
* declare a prop with the same name that you added the filter config to `primaryFilters` or
`secondaryFilters`
* resolve the filters initial value with `initialValue` and `initialValues` methods
* use the `SelectSingleFilterPlain` and `SelectMultipleFilterPlain` components inside the
`<div className={css.filtersWrapper}>` element to render the filters