Open johnboxall opened 1 year ago
Thanks @johnboxall for raising this issue, we've created a work item in our backlog to track this work
I tried the steps above again but it appears no longer possible to get the test app to successfully run.
First I build the lib:
nvm use 18
corepack enable
yarn install
yarn run renderTemplates
yarn build:lib
Second I tried to run the app:
NODE_OPTIONS=--openssl-legacy-provider HTTPS=true react-scripts start
The cert that shipped with the older version of CRA we use appears to not be compatible with modern Node versions so I introduced a new flag. Though I was able to get it to start (and bypass the TLS warning with thisisunsafe
) I still had TLS errors in browser when trying to connect via the proxy to Commerce API.
In addition I needed to make the following changes:
package.json::proxy
to use a real shortcode.searchText
in src/environment/App/App.jsx
to refer to something that returns results (eg. dress
)src/environment/config.js
with real settingssrc/static/helpers/slasHelper.ts
to skip handling errors from following the callbackGoing forward, I think we have a few options:
All of this might be easier when SCAPI ships support for CORS (removing the need for a proxy) which should come up in B2C Commerce ~24.10-ish.
Until then, an easy-ish way to test this library is to use pwa-kit-create-app@2
to generate a project where you can then edit calls to the PWA Kit:
npx pwa-kit-create-app --outputDir pwa-kit-2
Now edit this file:
commerce-sdk-isomorphic
ships with a neat little test app based oncreate-react-app@4.3.0
It is challenging to get the app working.
thisisunsafe
.package.json
, providing a valid shortcode.src/config.js
needs to be updated with valid values.https://localhost:3000/callback
be a valid redirect URI.authorize
will be followed, and CRA doesn't know how to render/callback
: https://github.com/SalesforceCommerceCloud/commerce-sdk-isomorphic/blob/414ff5850715d624df5f2193371a1638708760ed/src/static/helpers/slasHelper.ts#L140-L145It is possible to jump through these hoops, but challenging:
A few ideas:
authorize
helper to be more forgiving. We do care if the initial call toauthorizeCustomer
failed, but in the event that we're running in a browser, we actually do not care if we followed a redirect and the redirect failed to load, as we can still get the usid/code out of the URL, regardless of the status code of loadingredirect_uri
.