Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: #49/shipping billing #51

Merged
merged 18 commits into from
Aug 25, 2021
Merged

feat: #49/shipping billing #51

merged 18 commits into from
Aug 25, 2021

Conversation

Baroshem
Copy link
Contributor

@Baroshem Baroshem commented Aug 20, 2021

Closes #49

Description

Saving and loading shipping and billing data works, now I have to also fetch the shipping methods.

EDIT: Fetching Shipping Methods work but now I also have to figure out how to update the cart object.

EDIT: Everything works

Screen.Recording.2021-08-22.at.13.41.31.mov

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@Baroshem Baroshem self-assigned this Aug 20, 2021
@Baroshem Baroshem changed the title feat: #49/shipping billing [WIP] feat: #49/shipping billing Aug 22, 2021
@Baroshem
Copy link
Contributor Author

@michaelbromley If you could take a look at GraphQL queries, mutations and fragments and @Mateuszpietrusinski if you could do a general check of this feature that would be great. I can offer a cute cat picture in return:

image

Copy link

@Mateuszpietrusinski Mateuszpietrusinski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of work has been done 👍 .

import eligibleShippingMethodsQuery from '../../src/api/getShippingMethods/eligibleShippingMethodsQuery';
import { Context } from '../../src/types';

describe('[vendure-api-client] getShippingMethods', () => {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

think about different scenarios, like apollo client function should have been called with passed params

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now, all unit tests are pretty basic stuff. I will refactor them later so that they will serve more purpose.


const { data } = await updateAddressDetails(context, { input: givenVariables.input });

expect(data).toBe('update shipping details response');

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can extract string into a variable and place it into a given section with the name expectedAddressDetails this will contribute to readability.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call!

const request = await context.client.mutate({
mutation: gql`${updateAddressDetails.query}`,
variables: updateAddressDetails.variables,
fetchPolicy: 'no-cache'

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe its good to move that const into global variable

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is used in many places. Thanks for noticing that!

@@ -1,3 +1,4 @@
export * from './mockedCollectionList';

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comment related to folder name :
Jest recommends to name mocks folder with underscores https://jestjs.io/docs/manual-mocks#mocking-user-modules.
So instead of mocks you will have __mocks__.
Here you can find examples https://jestjs.io/docs/manual-mocks#examples

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excelent, I will correct that :)

const response = await load(context, {});

expect(response).toBe(loadedBillingAddress);
expect(context.cart.load).not.toHaveBeenCalled();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just wondering why are you used .not in this place?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copy/paste from CT project. Should probably remove it

const params: UseBillingParams<OrderAddress, AddParams> = {
provide() {
return {
cart: useCart()
Copy link

@Mateuszpietrusinski Mateuszpietrusinski Aug 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO you can have some issues when you use other composable outside setup function, but let me know if error occur sometimes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no error and we are using similar functionality in order integrations as well. Is it because in some cases we are fetching the data that we already have so better approach would be to reuse the data.

@@ -3,23 +3,34 @@ import {
useBillingFactory,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the logic for billing is related to cart at the backend maybe think about extending cart composable instead of covering useBilling. This approach will give you the ability to have cart value available out of the box.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shipping, Billing and Shipping provided is all related to cart but I thought that it would be better to have it separate as it requires different mutations/queries to be performed.


const params: UseShippingParams<ShippingAddress, AddParams> = {
const params: UseShippingParams<OrderAddress, AddParams> = {
provide() {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK UseShippingParams by default don't have provide function, are everything works well for TS?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, AFAIK everything is working correctly. No errors what so ever.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, FactoryParams shipps provide fucntion

</div>
<div v-else-if="errorShippingProvider.save">
<SfLoader :loading="loadingShippingProvider">
<div v-if="errorShippingProvider.save">

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it's better to place errorShippingProvider.save into a variable and maybe I'm wrong but if errorShippingProvider is computed you need to access the value in this way errorShippingProvider.value.save

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the template we do not have to use .value

Copy link
Collaborator

@michaelbromley michaelbromley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The queries & fragments look fine to me.

One thing I was wondering about: I could not see whether you are handling the ErrorResult cases for the various mutations. Very possibly I just was unable to locate this code given my unfamiliarity with the patterns.

@Baroshem
Copy link
Contributor Author

The queries & fragments look fine to me.

One thing I was wondering about: I could not see whether you are handling the ErrorResult cases for the various mutations. Very possibly I just was unable to locate this code given my unfamiliarity with the patterns.

For now I was just passing the basic ErrorResult fragment from the query/mutation. The error will be available in the error property of certain factory (like useShippingFactory) and can be accessible in the theme (frontend of the frontend ;)) but I also do not wanted to add to much complexity into one PR. I will create an issue to add other errors as framgents and error handling

@Baroshem Baroshem merged commit 59ccdf3 into main Aug 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature]: develop shipping and billing functionality
3 participants