Issues with Cart Address Validation about storefront HOT 22 CLOSED

I've made some improvements in my branch for US address check out, fighting with the stripe integration next as the checkout simply doesn't show any errors or order confirmation when I try to check out.

from storefront.

I opened a discussion with instructions on how to run the checkout and storefront if you're interested. React-storefront & checkout integration #209

from storefront.

@simon-online In my fork I added the form validation errors to the output on the screen. I also changed my defaults to US and added the countryRegion (state) field. Checkout works, but no organic sales yet.

from storefront.

I will give it a try. Am I supposed to run 5 separate apps instead of 3? Backend + react-storefront + checkout + checkout-app + dashboard? That seems a bit complicated. Dockerfiles are missing in checkout and checkout-app so I will probably need to create them myself.

from storefront.

Following. Stuck on this.

from storefront.

Have you looked at using saleor-checkout with this storefront?

from storefront.

No, I am not familiar with it other than reading it's name in another thread that sounded like it was going to be released soon. Any additional details?

from storefront.

Also, FYI -- I got the stripe check out working too last night, so it works but its wonky with the telephone and address validation requiring a very specific phone number with the +country code in front and no other formatting. I also had to expose the countryArea field and the "use same address as billing" for shipping address button does not work. I am kind of imaging just customizing my fork of the react-storefront to fill in the gaps slowly overtime to what I personally might need, but open to if there are better suggestions. Also is there any guide on how to theme and style the site or do you basically have to fork it and get to work?

from storefront.

No, I am not familiar with it other than reading it's name in another thread that sounded like it was going to be released soon. Any additional details?

I haven't got it to work yet but I have seen it working from the PR previews, it fixes and streamlines the checkout from the storefront. I've been trying to get it configured but haven't made any major headway. Added some issues on it though. Hopefully we can get it working soon.

from storefront.

I had the same problem with the country code and phone number. I'm just rewriting the field inputs on the post so that it can be entered naturally. I was going to do the same thing you are doing and fixing the issues myself until I saw the checkout.

from storefront.

@wileyknight I have fixed this is my react-storefront branch -- what advantage would using the separate checkout repository? It seems like more overhead to me and would require deploying now a 4th docker container to run the site -- I am pretty happy without going in this direction and using the checkout code that is in this repository that I have modified in my fork to fix a few bugs.

from storefront.

Yes the current react-storefront checkout user experience isn't great with strict phone and address validation and no error messages displaying. It definitely could be improved to provide a better testing experience.

However I was able to successfully complete the checkout without modifying the code by providing an international phone number eg. +48123456789 and entering in an address in Poland. eg.

Address:
Tęczowa 7

City:
Wrocław

Postal code:
53-601

from storefront.

@matteius

This will help with the phone number validation:

Above the return on AddressForm.tsx

const phoneFormatHandler = (arg0: any): string => {
  
    const reformatted = `+1${arg0}`;

    if (arg0.slice(0,1) !== "+") {
      if (arg0.slice(1,2) !== "1") {
        return reformatted;
      } 
      return reformatted;
    }
    
    if (arg0.slice(0,1) !== "1") {
      return reformatted;
    } 
    
    return arg0;
  }

and in the phone input:

{...registerAddress("phone", {
  required: true,
  pattern: /^([+]?[\s0-9]+)?(\d{3}|[(]?[0-9]+[)])?([-]?[\s]?[0-9])+$/i,
  setValueAs: e => phoneFormatHandler(e),
})}

Now customers wont have to add the + or the 1 for the phone number to go thru.

from storefront.

@matteius

I made that way too complicated... I was testing and realized that this works just but adding

setValueAs: e => e.slice(0,1) === "1" ? e : `1${e}`,

to the input.

And update:

phone: existingAddressData?.phone?.replace("+", "") || "",

from { ... } = useFormAddressFormData>({ ... })

from storefront.

I think this was fixed recently when I merged upstream into my branch (or in the upstream saleor backend) -- I can enter my number with area-code only and it gets saved with the +1 -- the only real issue I am having with the address flow right now is that my form defaults the countryArea (state) field to be United States instead of my billing state ME -- seems less than ideal, but also wasn't why I opened this issue originally.

from storefront.

@matteius

I was still having problems with my form when saving so I made the aforementioned change... I am not using the most updated backend, yet, but this fixed it from the frontend side.

I had the same problems as you with the State and had to make the changes to include countryArea as State to get it working. I am not having trouble with it defaulting to to the country though. It looks like we have the exact same fixes for the country area except your description in translations.ts still says country area. description: "Country area field label.", description: "State field label.",

Maybe convert that to a selector with options for the abbreviated state names. Amazon is using that type of input, not to say it's the best, but it's familiar.

from storefront.

Why this is closed as completed? I tested this on latest backend+storefront and all the issues OP described are still there.

from storefront.

This isn't the first time this has happened. Many issues have been closed as completed that have not.

from storefront.

@wileyknight @gleniat please use saleor-checkout repo, we are in process of merging both projects, checkout page in this repository would be dropped

from storefront.

@gleniat None of the front end projects need docker, they are next.js projects and can be easily deployed to Vercel. Dashboard is a react SPA which can be served as a static files. I strongly recommend you not to use docker for local development and specially for production.

I agree that the setup is a bit complicated, but there are good reasons and advantages of separated packages. Storefront is meant to be modified while checkout is quite complex to maintain and can be convenient to upgrade as we ship improvements.

We provide CLI tool to automate development and deployment process as well as free saleor cloud accounts to run dashboard and backend.

from storefront.

What is the difference between checkout and checkout-app? For those of us not deploying to Vercel, probably those other projects do require Docker or at least that is the most obvious way outside of Vercel, or are they like Dashboard in that they can be deployed as static files? I think it would be nice, even if they are separate repositories, to be able to include the frontend in a single Docker container running behind a single pnpm server.

from storefront.

@matteius checkout app is a saleor app for managing checkout theme and processing payments. Checkout is a static SPA, checkout app is a next js application

from storefront.