Releases: sharetribe/ftw-daily
v8.4.1
Changes v8.4.1
- [fix] Portal version of Modals couldn't use 100vh on mobile Safari. Safari changes the window's
height based on if the location bar is squeezed or not (and that depends on scroll-effect).
#1501 - [fix] Setting multiple environment variables in Windows requires using the set command before each
individual variable. Updated the 'for windows users' section in documentation.
#1491 - [add] Code comment about "REACT_APP" prefix in environment variables.
#1492
v8.4.0
Changes v8.4.0
Mainly bug fixes and library updates.
-
[fix] Mobile safari zooms if input-related elements have smaller font-size than 16px. This updates
textarea and select element styles too. #1489 -
[fix] Dependabot: Bump passport-oauth2 from 1.5.0 to 1.6.1
#1487 -
[fix] Fix bugs in checkout process:
- Submit button was enabled prematurely for onetime payments
- Toggling between default card and onetime payment flows was not working correctly in case of
error (e.g. network error). - Calling Stripe.confirmCardPayment when status is requires_capture is unnecessary.
-
[change] Update many dependencies. See full list in the package.json changes in the PR.
#1483 -
[fix] Double click issue. Show dedicated message, when current user doesn't have a pending email
address, but there's a verification error.
#1485 -
[change] Update comment about how scrollIntoView works with links using hash.
#1484 -
[fix] Account pages: mobile tab navigation should only scroll horizontally
#1481 -
[fix] Temporarily disallow Node v17, since it causes issues with dependencies.
#1479 -
[fix] Fix modal close button text/icon alignment
#1476
v8.3.0
Changes v8.3.0
- [change] Increase input font size on mobile to avoid Mobile Safari zooming in when focusing on
inputs. #1473 - [change] Update browserlist data to match modern browsers.
#1468 - [fix] Font-size was too big for Stripe Elements on small screens on PaymentMethodsForm.
#1471 - [fix] Remove unnecessary language import: fr.json
#1469 - [fix] Font-size for Poppins font was too big for Stripe Elements on small screens.
#1465 - [change] Updates to some of the libraries. React Intl had a breaking change v3 -> v5.
#464 - [fix] Adblockers might block Google analytics (window.ga) and cause an error.
#1462
v8.2.0
Changes v8.2.0
- [change] Update lodash version number in package.json resolutions section.
#1459 - [change] Dependabot update: url-parse (v1.5.1)
#1436 - [change] Dependabot update: lodash (v4.17.21)
#1437 - [change] Dependabot update: tar (v4.4.15)
#1457 - [change] Dependabot update: ws (v6.2.2) #1446
- [change] Dependabot update: hosted-git-info (v2.8.9)
#1438 - [change] Dependabot update: trim-newlines (v3.0.1)
#1449 - [change] Update sharetribe-scripts to version 5.0.1 which improves the instructions that are shown
after running yarn build command. #1458 - [fix] Remove unused dep-resolution: handlebars.
#1456 - [fix] PriceFilterPopup: filter popup is not closing when clicking outside on Safari.
#1455 - [fix] Add missing helper: isNumber. Used when Number.MAX_SAFE_INTEGER is reached.
#1453 - [fix] minutesBetween: remove thrown an error on negative diff.
#1444 - [fix] TransactionPanel: fix typo #1451
- [fix] searchMode (has_all/has_any) disappeared, when search-by-moving-the-map was used.
#1443
v8.1.1
Changes v8.1.1
- [change] Update jose to v3.11.4 #1433
- [add] Update fr.json, es.json and partially de.json
#1431 - [fix] currency conversion should not expect that env-variable is set.
#1425 - [fix] LoadableComponentErrorBoundary should be used in prod, not in dev-mode with hot-loading.#1429
- [fix] currency for Poland (PLN) #1427
Includes also dependabot updates:
- Bump y18n from 4.0.0 to 4.0.1
- Bump react-dev-utils from 11.0.2 to 11.0.4
- Bump ssri from 6.0.1 to 6.0.2
v8.1.0
Minor release with couple of fixes.
The biggest thing is probably LoadableComponentErrorBoundary, which handles situations where deploy changes the chunks (hashes) and online user can't load those chunks that it expects to get from server.
Changes v8.1.0
- [change] Specify required Node.js versions in package.json and update the node version used in CircleCI. Currently, the required Node.js version comes from jose package which is used with social logins.
#1418 - [fix] enforce upper case for currency and improve error message for it.
#1417 - [add] Add
LoadableComponentErrorBoundary
for handling ChunkLoadErrors with error boundary.
#1416
v8.0.0
Previously, sharetribe-scripts created one UMD build that was used on both server and frontend. I.e. all the code used in the app was bundled into a single main.bundle.js file and that was used on the web app and server.
Unfortunately, this has meant that code-splitting was not supported: it didn't work with UMD build due to an old bug in Webpack.
With this major release (using sharetribe-scripts v5.0.0), we are changing this behaviour: sharetribe-scripts creates 2 different builds when yarn run build
is called. Basically, this means that build-time increases (including yarn run dev-server
call).
However, this setup makes code-splitting possible. To make this easier, we have added Loadable Components library to the setup.
What is code splitting
Instead of downloading the entire app before users can use it, code splitting allows us to split the code (from one main.bundle.js file) into smaller chunks which you can then load on demand. To familiarize yourself with the subject, you could read about code splitting from reactjs.org.
In practice, we have used route-based code splitting: page-level components are now using Loadable Components syntax to create dynamic imports functionality.
const AboutPage = loadable(() => import(/* webpackChunkName: "AboutPage" */ './containers/AboutPage/AboutPage'));
When module bundler comes across these loadable objects, they will create a new JS & CSS chunk files (e.g. AboutPage.dc3102d3.chunk.js). I.e. those code-paths are separated from the main bundle.
Previously, when you loaded /about
page, you received main.bundle.js & main.bundle.css, which were pretty huge files containing all the code that was needed to create FTW-daily and any page inside it. Loading a single file takes time and also browsers had to evaluate the entire js-file, before it was ready to make the app fully functional.
So, the main benefit of code splitting is to reduce the code that is loaded for any single page. That improves the performance, but even more importantly, it makes it possible to add more navigational paths and page-variants to the codebase. For example, adding different kind of ListingPages for different types of listings makes more sense with code-splitting. Otherwise, new pages would have performance impact on initial page load and therefore SEO performance would drop too.
Note: currently, most of the code is in shared src/components/ directory and this reduces the benefits that come from code-splitting. In the future, we are probably going to move some components from there to page-specific directories (if they are not truly shared between different pages).
How code splitting works in the new code
With code-splitting, this resource loading setup changes a bit. If you open /about
page on top of this branch, you'll notice that there are several JS & CSS files loaded:
- Main chunk (e.g. main.1df6bb19.chunk.js). It contains code that is shared between different pages.
- Vendor chunk (Currently, it's an unnamed chunk file. e.g. 24.230845cc.chunk.js)
- Page-specific chunk (e.g. AboutPage.dc3102d3.chunk.js)
- Runtime chunk (e.g. runtime-main.818a6866.js)
This one takes care of loading correct JS & CSS files when you navigate to another page inside the web app.
(e.g. it loads LandingPage.6fa732d5.chunk.js && LandingPage.40c0bf91.chunk.css, when you navigate to landing page.)
So, there are several chunk files that can be loaded parallel in the first page load and also page-specific chunks that can be loaded in response to in-app navigation.
Naturally, this means that during in-app navigation there are now more things that the app needs to load: data that the next page needs and code chunk that it needs to render the data. The latter is not needed if the page-specific chunk is already loaded earlier.
How flickering is optimized with preloading
This means that there might be a fast flickering of blank page when navigation happens first time to a new page. To remedy that situation, we have forced the page-chunk to be preloaded when mouse is over NamedLink. In addition, Form and Button components can have a property enforcePagePreloadFor="SearchPage"
. That way the specified chunk is loaded before the user has actually clicked the button or executed form submit.
Changes to route configuration
To make this preloading possible, we refactored routes in routeConfiguration.js file a bit: Loadable component is directly set to "component" conf:
// const AuthenticationPage = loadable(() => import(/* webpackChunkName: "AuthenticationPage" */ './containers/AuthenticationPage/AuthenticationPage'));
{
path: '/signup',
name: 'SignupPage',
- component: props => <AuthenticationPage {...props} tab="signup" />,
+ component: AuthenticationPage,
+ extraProps: { tab: 'signup' },
},
Change to loadData function setup
Another change is how loadData & setInitialValues static functions work. Since page component is now a Promise (since page chunk is loaded asynchronously), we had to access those functions differently. To minimize the needed changes, we ended up collecting those Redux functions through duck-files - similarly than how src/containers/reducers.js does. So, all the loadData and setInitialValues functions are collected in src/containers/pageDataLoadingAPI.js. For routing, this means changes like:
{
path: '/l/:slug/:id',
name: 'ListingPage',
- component: props => <ListingPage {...props} />,
- loadData: ListingPage.loadData,
+ component: ListingPage,
+ loadData: pageDataLoadingAPI.ListingPage.loadData,
},
This also forced us to standardize the location of loadData functions. Some of the pages have had those is page's main file and not in the duck.js file - most notably SearchPage. Now all the loadData functions are defined in page's own modular Redux file (i.e. SomePageComponent.duck.js).
CSS chunk changes
To ensure that every page-level CSS chunks have custom media queries included, we have separated those breakpoints to src/styles/customMediaQueries.css file and imported it to every page's stylesheet.
Server-side rendering (SSR)
Because pageDataLoadingAPI.js allowed us to keep the routeConfiguration.js file pretty close to original setup, the data loading for SSR works pretty much the same as before:
- server/dataLoader.js initializes store
- it also figures out which route is used
- If there's loadData function set, the call is dispatched
- As a consequence, the store gets populated and it can be used to render the app to a string.
However, Loadable Components setup did change the way we import the app-related code:
- build directory contains now node subdirectory.
- Both builds have also loadable-stats.json file (which basically tells what assets different pages need).
- server/importer.js exposes two ChunkExtractors - one for web and another for node build.
- server/index.js requires entrypoint from node build and passes relevant info to dataLoader.loadData() and rendered.render() calls.
- Web extractor is used to collect those chunks that the current page-load needs.
In practice,renderApp
function wraps the app with webExtractor.collectChunks and with that webExtractor can figure out all the relevant loadable calls that the server uses for the current page and therefore the web-versions of those chunks can be included to rendered pages through<script>
tags.
Changes v8.0.0
- [fix] Remove unintended Lodash usage, unspecified window-scope calls and unused vars
#1413 - [add] Route-based code splitting. This is done against sharetribe-scripts v5.0.0 using Loadable
components. Read more from the pull request.
#1411
Taking update from upstream
Check the pull requests carefully! Here are couple of extra highlights:
- src/routeConfiguration.js has changed (we added route-based code splitting)
const AboutPage = loadable(() => import(/* webpackChunkName: "AboutPage" */ './containers/AboutPage/AboutPage'));
- The setup of "loadData" & "setInitialValues" functions have changed. Those functions need to be defined in "duck" files (SomePage.duck.js) and exposed through
src/containers/pageDataLoadingAPI.js
- Due to code splitting, we have separated Custom Media Queries.
src/styles/marketplaceDefaults.css
->src/styles/customMediaQueries.css
Every dynamically imported page need to import that file to ensure that page-specific CSS chunk knows how to convert breakpoints correctly.@import '../../styles/customMediaQueries.css';
- NamedLink component checks if the named route contains Loadable component and preloads the page-specific chunks when user hovers with mouse over the link.
- Button and Form elements have a new property
enforcePagePreloadFor="SearchPage"
that can enforce the same behaviour (it's useful, if the element is makinghistory.push
navigation to a new page.
v7.3.0
Changes v7.3.0
- [fix] Move well-known/* endpoints related to OIDC proxy setup from
apiRouter
to new
wellKnownRouter
so that they can be enabled outside the basic auth setup. It also makes it
simpler to set the identity provider url, because we can drop the/api
part of the path. Also,
rename theRSA_SECRET_KEY
toRSA_PRIVATE_KEY
for consistency.
#1399 - [fix] Make sure that the verify email API endpoint has been called successfully before redirecting
the user away from EmailVerificationPage.
#1397
v7.2.0
v7.1.0
Changes v7.1.0
- [change] Handle entity update with sparse attributes.
#1392 - [change] Remove react-google-maps dependency. It has not been maintained for 3 years. From now on,
we use Google Maps API directly. However, the default map provider is still Mapbox.
#1389 - [fix] Pass metadata through sanitizeUser function.
#1391 - [fix] Call for the same page caused unnecessary rendering
#1388 - [fix] Fix Google Maps default centering if no bounds or center is given.
#1386 - [add] Add timeout and other options for getCurrentLocation call.
#1385 - [fix] Fix FieldCheckbox validation on blur event on Firefox.
#1384