mirror of
https://github.com/kingomarnajjar/flex-template-web.git
synced 2026-07-28 12:43:11 +10:00
Fix typos and broken links.
This commit is contained in:
parent
c50dc86559
commit
9aaa62f072
8 changed files with 32 additions and 33 deletions
|
|
@ -25,7 +25,7 @@ See the [Environment configuration variables](docs/env.md) documentation for mor
|
|||
required configuration variables.
|
||||
|
||||
**Note:** If you want to build your own Flex marketplace on top of the template, you should fork the
|
||||
repository instead of cloning it. See the following section.
|
||||
repository instead of cloning it. See the [Customization guide](./docs/customization-guide.md).
|
||||
|
||||
## Getting started with your own customization
|
||||
|
||||
|
|
|
|||
|
|
@ -13,19 +13,19 @@ used in a browser environment using the JavaScript SDK.
|
|||
|
||||
Marketplace features included in Saunatime:
|
||||
|
||||
* **Location search** shows the user if there are saunas available in given location.
|
||||
* **The listing page** gives a detailed view about what this particular sauna offers.
|
||||
* **Location search** shows the user if there are saunas available in a given location.
|
||||
* **The listing page** gives a detailed view about what a particular sauna offers.
|
||||
* **Transaction process**: Saunatime uses nightly booking.
|
||||
* **Notifications**: Emails are sent during the booking process to alert customers and providers
|
||||
about changes in the booking state.
|
||||
* **Inbox** lists **orders** and **sales**
|
||||
* **Reviews** can be given after a completed transaction
|
||||
* **User profiles** are which can provide detailed information about a given user
|
||||
* **Inbox** lists **orders** and **sales**.
|
||||
* **Reviews** can be given after a completed transaction.
|
||||
* **User profiles** provide detailed information about a given user.
|
||||
* **Extended data:** The listing and user data models are modified using extended data.
|
||||
|
||||
## How to customize this template
|
||||
|
||||
The easiest way to start a customization project is to read through our
|
||||
The easiest way to start a customization project is to read through the
|
||||
[customization guide](customization-guide.md). After that, you probably should start with changing
|
||||
[translations](translations.md), [common styles](styling.md) in marketplace.css, and then create
|
||||
[static pages](static-pages.md) and modify
|
||||
|
|
@ -36,7 +36,7 @@ Documentation for specific topics can be found in the following files:
|
|||
* [Customization guide](customization-guide.md)
|
||||
* [Folder structure](folder-structure.md)
|
||||
* [Translations](translations.md)
|
||||
* [Styling marketplace](styling.md)
|
||||
* [Styling a marketplace](styling.md)
|
||||
* [Static pages](static-pages.md)
|
||||
* [Terms of Service and Privacy Policy](terms-of-service-and-privacy-policy.md)
|
||||
* [Extended data](extended-data.md)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Some generic things to update and check when starting to customize the template.
|
|||
|
||||
* [Marketplace colors](styling.md)
|
||||
* [Generate app icons](icons.md)
|
||||
* [Update translations](../src/translations/en.json) or [change the language](i18n.md)
|
||||
* [Update translations](../src/translations/en.json) or [change the language](translations.md)
|
||||
* [LandingPage](../src/containers/LandingPage/LandingPage.js): update and create branded sections
|
||||
* [Footer](../src/components/Footer/Footer.js)
|
||||
* [AboutPage](../src/containers/AboutPage/AboutPage.js)
|
||||
|
|
@ -14,7 +14,7 @@ Some generic things to update and check when starting to customize the template.
|
|||
* [Logo](../src/components/Logo/Logo.js) Change and check that it works on Topbar and Footer
|
||||
* [Logo in CheckoutPage](../src/containers/CheckoutPage/LogoIcon.js)
|
||||
* [Default background image](../src/assets/background-1440.jpg)
|
||||
* [Maps Marker icon](../src/components/Map/Map/images/marker-32x32.png)
|
||||
* [Maps Marker icon](../src/components/Map/images/marker-32x32.png)
|
||||
* [Config: update environment variables](../src/config.js)
|
||||
* [Config: siteTitle](../src/config.js) for page schema (SEO)
|
||||
* [Config: marketplace address](../src/config.js): contact details also improve SEO
|
||||
|
|
@ -25,10 +25,9 @@ Some generic things to update and check when starting to customize the template.
|
|||
* Update [EditListingWizard](../src/components/EditListingWizard/EditListingWizard.js) and panels to
|
||||
add extended data
|
||||
* Update [SearchPage](../src/containers/SearchPage/SearchPage.js) to filter with extended data
|
||||
* Update [routeConfiguration](../src/routeConfiguration) if needed
|
||||
* Update
|
||||
[Email templates](https://github.com/sharetribe/sharetribe-starter-app/tree/master/ext/mail-templates),
|
||||
all of them: .html, subject.txt, and text.txt
|
||||
* Update [routeConfiguration](../src/routeConfiguration.js) if needed
|
||||
* Update [Email templates](../ext/default-mail-templates), all of them: .html, subject.txt, and
|
||||
text.txt
|
||||
* Update [config: bookingUnitType](../src/config.js) if needed
|
||||
* If `line-item/units` is used, add quantity handling to
|
||||
[BookingDatesForm](../src/forms/BookingDatesForm/BookingDatesForm.js),
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
So you've decided to build your own Flex marketplace using the template. That's awesome! This guide
|
||||
will help you in setting up your fork and describes the general workflow.
|
||||
|
||||
**Note:** if you cloned the repository like described in the Quick start section of the project
|
||||
**Note:** If you cloned the repository like described in the Quick start section of the project
|
||||
README file, you probably don't want to make the customizations in that project. Forking the
|
||||
repository is the recommended way to proceed. Follow this guide for instructions.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Adding new attributes to the data model relies on a Flex concept called
|
|||
|
||||
Three main areas in extending the listing data model are:
|
||||
|
||||
* [Declare the attribute and it's possible values](#declare-the-attribute-and-it-s-possible-values)
|
||||
* [Declare the attribute and it's possible values](#declare-the-attribute-and-its-possible-values)
|
||||
* [Edit the listing wizard](#edit-the-listing-wizard)
|
||||
* [Show the attribute on listing page](#show-the-attribute-on-listing-page)
|
||||
* [Use the attribute as a search filter](#use-the-attribute-as-a-search-filter)
|
||||
|
|
@ -69,8 +69,8 @@ export const PHOTOS = 'photos';
|
|||
export const SUPPORTED_TABS = [DESCRIPTION, FEATURES, CAPACITY, POLICY, LOCATION, PRICING, PHOTOS];
|
||||
```
|
||||
|
||||
Now in`EditListingWizard` we can take that tab declaration into use. Add the tab name to the `TABS`
|
||||
array and add a correct label for the tab.
|
||||
Now in `EditListingWizard` we can take that tab declaration into use. Import the tab name variable
|
||||
from `EditListingWizardTab` and add it to the `TABS` array.
|
||||
|
||||
```js
|
||||
export const TABS = [DESCRIPTION, FEATURES, CAPACITY, POLICY, LOCATION, PRICING, PHOTOS];
|
||||
|
|
@ -104,8 +104,8 @@ const tabLabel = (intl, tab) => {
|
|||
The `tabCompleted` function keeps track of which data the user has already provided in order to tell
|
||||
which tabs are completed. As we will be storing the capacity information in the listing's _public
|
||||
data_ property (see the [extended data](./extended-data.md) documentation for more info on different
|
||||
extended data types) we shall look into that property when when resolving whether the capacity tab
|
||||
has alerady been completed or not:
|
||||
extended data types) we shall look into that property when resolving whether the capacity tab has
|
||||
alerady been completed or not:
|
||||
|
||||
```js
|
||||
/**
|
||||
|
|
@ -391,7 +391,7 @@ in our case with the capacity information we want to show the added attribute in
|
|||
for potential customers.
|
||||
|
||||
To show the capacity attribute in the listing page, let's create a specific component for it and
|
||||
place it in the `ListingPage` container. Desired outcome could be achieved just by editing the
|
||||
place it in the `ListingPage` container. Desired outcome could also be achieved just by editing the
|
||||
`ListingPage` but extracting the capacity UI parts into a separate component will simplify the
|
||||
`ListingPage` and make possible upstream updates from the Flex web template repo easier as there's
|
||||
less chances for merge conflicts. So, let's create a `SectionCapacity` component in the
|
||||
|
|
@ -461,7 +461,7 @@ ListingPageComponent.propTypes = {
|
|||
```
|
||||
|
||||
In the snippet above, the capacity options are passed to the `ListingPage` as a property, with the
|
||||
default proprty value pulling the options from the custom config (`marketplace-custom-config.js`).
|
||||
default property value pulling the options from the custom config (`marketplace-custom-config.js`).
|
||||
This way the listing page test can define it's own capacity options that are in line with test data
|
||||
used in the test and custom config changes will not affect test results.
|
||||
|
||||
|
|
|
|||
|
|
@ -86,10 +86,10 @@ _**NOTE:** Currently, we are migrating to
|
|||
## server/
|
||||
|
||||
* `server/index.js` handles server-side rendering (SSR). Built with [Express](http://expressjs.com)
|
||||
(Node.js framework)
|
||||
* `server/csp.js` [content security policy](https://content-security-policy.com) A whitelist of
|
||||
(Node.js framework).
|
||||
* `server/csp.js` [Content Security Policy](https://content-security-policy.com), whitelist of
|
||||
domains that the application and loaded scripts are allowed to access from the browser.
|
||||
* `server/sitemap.js` generates a minimal sitemap.xml for SEO purposes
|
||||
* `server/sitemap.js` generates a minimal sitemap.xml for SEO purposes.
|
||||
|
||||
## ext/default-mail-templates/
|
||||
|
||||
|
|
@ -98,4 +98,4 @@ _verify-your-email_). You should customize all the different files (\*-html.html
|
|||
and \*-text.txt).
|
||||
|
||||
_**NOTE:** Changing these doesn't change actual email templates - you need to send customized
|
||||
templates to your FLEX contact person._
|
||||
templates to your Flex contact person._
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
# Flex Template for Web: styling
|
||||
|
||||
The goal for creating styling for Flex template app was to keep styling as close as possible to
|
||||
plain CSS writing while still trying to avoid the mess that comes along with globally defined
|
||||
cascading behavior that CSS is all about.
|
||||
plain CSS while still trying to avoid the mess that comes along with globally defined cascading
|
||||
behavior that CSS is all about.
|
||||
|
||||
To tackle this goal, we have split the styling into two levels in this template application:
|
||||
|
||||
|
|
@ -71,7 +71,7 @@ marketplace color to tomato color. (It's a certain kind of red color.)
|
|||
The `--marketplaceColorEncoded` variable holds the same value as `--marketplaceColor` but with the
|
||||
_#_ URL encoded. This value can be used to maintain a consistent color scheme with inline SVG icons.
|
||||
|
||||
`--successColor` (green) is used on form inputs for showing that the input value is valid.
|
||||
`--successColor` (green) is used in form inputs for showing that the input value is valid.
|
||||
Sometimes, submit buttons (`<PrimaryButton>`) are also using that color to highlight the fact that
|
||||
user has entered valid information to the form at hand.
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ _marketplaceFonts.css_ are included to _marketplace.css_, so you don't need to i
|
|||
new components (importing _marketplace.css_ is enough).
|
||||
|
||||
⚠️ NOTE: template app is following a pattern where the height of an element should be divisible by
|
||||
`6px` on mobile layout and `8px` on bigger layouts. This affects to line-heights of font styles too.
|
||||
`6px` on mobile layout and `8px` on bigger layouts. This affects line-heights of font styles too.
|
||||
|
||||
⚠️ NOTE: the `@apply` rule and custom property sets most likely won't get any more support from
|
||||
browser vendors as the spec is yet considered deprecated and alternative solutions are being
|
||||
|
|
@ -143,7 +143,7 @@ This file provides default styles for plain elements like `<body>`, `<a>`, `<p>`
|
|||
|
||||
## Styling components
|
||||
|
||||
Styling a web UI is traditionally quite a messy business due to global nature of stylesheets and
|
||||
Styling a web UI is traditionally quite a messy business due to the global nature of stylesheets and
|
||||
especially their cascading specificity rule. `.card {/*...*/}` will affect every element on a web
|
||||
page that has a class `card` - even if the different UI context would like to use a different set of
|
||||
rules.
|
||||
|
|
|
|||
|
|
@ -125,8 +125,8 @@ namely `AboutPage`, `PrivacyPolicy`, and `TermsOfService`. The reason behind thi
|
|||
components only contain static content that is laid out in more of a document format so the
|
||||
translations for these texts can easily be changed and maintained in the component files themselves.
|
||||
|
||||
More information about adding static content to the application can be found from [the static pages
|
||||
documentation](./static-pages.md).
|
||||
More information about adding static content to the application can be found from
|
||||
[the static pages documentation](./static-pages.md).
|
||||
|
||||
## Changing the language
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue