The win-frontend from windingtree

story: Booking Page

Description:
A page after apartment selection, that navigates user through booking process personal data, payments etc.

Requirements:

story: improve web3 UX

Description:
Set of handlers and UI components that makes web3 UX easier and smoother.
Required:

Image fallback

Description:
Add a fall back for images that did not load successfully

Search results a list of cards with base facility info:

flowchart TD

	subgraph state[App state]
		searchResults
	end

	subgraph filters
		price[price asc/desc]
		amenities_filter[amenities]
	end
	
	subgraph results[Search results]
		offers_view[Foto, name, price]
	end
	
	state <--> useAppState
	useAppState --> filters
	useAppState <--> results
	
	filters_ui --> filters
	filters --> results

	subgraph offer_details[Offer details PAGE]
		details_view[Gallery, name, description, price, amenities]
	end

	results -.-> offer_details

searchResults state is persistent app state
when searchResults is changing filters must be recalculated
using filters_ui user can adjust search results data set
when the user selects a concrete offer he should be moved to a separate page
Facility name
Short facility description
Number of days
Title image of the facility
Total prices range
Book now button (see below)
amenties? as icons

Booking wizard (component)

flowchart TD
	details[Offers details PAGE] -.-> config[Offer configuration]
	config --> person[Personal information]
	person --> overview[Booking overview]
	overview -.-> book[Book now]

A booking wizard is definitely a wizard that guides the user through the three steps

Offer configuration (content should be discussed)
Personal information form
Booking request overview

At every step, it should be possible to move back

At the last step, the user should be able to start a booking process from the Book now component

At every step, the UI must demonstrate to the user offer an expiration time counter. If a timer is exhausted, the booking must be cancelled and the user should be moved to the search page.

This is the list of terms that is similar to the general terms list but these terms are strongly related to the options listed above. For example:
Remove breakfast
About how to display terms please see: Options and terms logic

Search service logic and data flow

flowchart
	subgraph state[App state]
		searchResults
	end

	subgraph useSearchForm
		validator
		queryBuilder
		querySender
	end

	subgraph form[Search form]
		address
		dates[check-in/out dates]
		guests
		num[Num rooms]
	end

	subgraph server
		search_api
	end

	querySender --> useDispatch
	useDispatch <--> state
	form <--> useSearchForm

	search[Search start] -.-> querySender

	querySender -.-> search_api

Address/city
Check-in/out dates selector
Guests (adult/children)
Num rooms

The Search form component should allow the following configuration*:

default address/city
default dates range

*This configuration must be provided via app config

useSearchForm hook accepts all the form properties as arguments.

When any of the arguments are changed in the state they must be validated and the search query is prepared to be sent to the server
When search is started by the user the querySender sends a request to the server

story: facility page

Description:
User should be redirected to Facility Page after choosing search option either from list or pin on map. Could be interpreted as a modal.

Required:

story: Footer

Requirements:

Crypto-payments component

As a user, I want to pay booking costs in stable coins (crypto) or native tokens.
I want to be able to select a proper network and choose an allowed token to pay.
I want to have the following possible payment options:

payment with a native token (actual for Gnosis Chain with xDAI)
payment with prior tokens approval
payment with permit (as an alternative to approval)

After successful payment, the component must call a callback with payment details.

The payment component must accept the following payment request object as an input parameter:

interface Payment {
  currency: AssetCurrency;
  value: BigNumber;
  expiration: number;
  providerId: string;
  serviceId: string;
}

Asset for a selected network must be filtered by the currency parameter. If the selected network does not contain proper assets for the user should be displayed a message: This network does not support payments in ${currency}

Main page NO header

Description:
Current implementation of map does not properly fit into a screen. Suggest to make header transparent, so it gives addition space for map

Options list

Options list is the list of the options that belong to the booking. For example:
Breakfast
Adult TV channels
SPA voucher
About how to display options please see: Options and terms logic

story: Search page

Description:
A main page with Map view, search filters and results.

Required:

Search filters (City/Address, Check-In/Out date selector, Adults, Children)
Advanced filters (Amenities selector)
#9
#10
Bid expiration indicator

Crypto-payments flow diagram

As a developer (front & back), I want to know the detailed payment process flow across all parties involved in the process.

The following information is required:

conditions of payment (all stages)
data models
sequence of payment flow process

story: my bookings page

Description:
A page with all users bookings list.

Required:

Book now

Book now (components)

flowchart
	subgraph book[Book now]
		network[Network selector]
		asset[Asset selector]
		guaranteeIdQuery
		cryptoPayment
		bookingFinalization
	end

	subgraph server
		booking[Booking API]
	end

	contract[Smart contract]

	offer[offer price, currency] --> book
	metamask <--> network
	asset -.-> balance
	guaranteeIdQuery -- request guaranteeId --> booking
	booking -.- guaranteeId -.-> guaranteeIdQuery
	guaranteeIdQuery -- guaranteeId --> cryptoPayment

	start[Start payment] -.-> cryptoPayment

	cryptoPayment <-- asset and price, guaranteeId, value --> contract

	cryptoPayment --> bookingFinalization
	bookingFinalization --> booking
	booking -.-> bookingFinalization

The Book now component accepts offer price and currency as params.

Network selector allows the user to select desired blockchain network (list of allowed networks must be configured via app config). When a user selects a network from the list the app must send special request to the Metamask wallet that changes the currently selected network.

Each network has its own set of crypto assets allowed for payments. Assets must be configured via app config.

The smart contract has two functions.

calc makes a calculation of the selected asset value and accepts the following arguments:
- asset (asset Id listed in the smart contract)
- booking price (fiat price)
pay makes crypto payment. Accepts the following arguments:
- asset (asset Id listed in the smart contract)
- booking price (fiat price)
- guaranteeId (Simard Pay, obtained through the booking API) OR offerID (???)
- asset value
- expiration time (sec) if during the transaction this time will be reached the transaction will be reverted

When the user selected the network the asset the component must send a calculation request using the calc function. After the calculation is obtained the UI must demonstrate to the user the required asset value.

If the balance of the asset in the user’s wallet is not enough in the UI must be generated warning message.
If the balance of the asset is enough for payment in the UI must be shown a button for starting payment.

The transaction expiration time must be calculated according to the following rule: transaction expiration time must be less than the offer expiration time. The difference between these times must be enough for the completion of the booking procedure via the Glider API.

When the payment transaction is mined the bookingFinalization helper must send a request to the booking API for making the booking via the Glider API.

When booking via the booking API is finished in exchange should be returned a booking ID. This Id should be demonstrated to the user and saved to the local storage into myBookings persistent property.

flowchart

	subgraph state[App state]
		myBookings
	end

	state <--> useAppState
	useAppState <--> bookingFinalization

light image carousel

Description:
Grommet native carousel is not meet our requirements, its too laggy.
Requirement:

Search for alternative options
Make own if non fits

windingtree / win-frontend Goto Github PK

win-frontend's People

Contributors

Stargazers

Watchers

Forkers

win-frontend's Issues

Booking wizard (component)

Book now (components)

Recommend Projects

Recommend Topics

Recommend Org