-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Bug #5537/newsletter functionality #5601
Conversation
- encapsulate logic, style, and template into separate form component - add local reactive object for newsletter checkbox - create updateNewsletterField method for handling checkbox status change - create submitForm method for submitting checked checkboxes
- move form template to separate component for easier reusability and readability - include useNewsletter in setup method - add onSSR lifecycle hook to load newsletter data - add method to updateNewsletter on form submit
Pull Request Test Coverage Report for Build 613559196
💛 - Coveralls |
💙 vsf-next-demo successfully deployed at https://90607d712e9e1aadc630117f7848c5f85287a340.vsf-next-demo.preview.storefrontcloud.io |
Pull Request Test Coverage Report for Build 613559196
💛 - Coveralls |
Pull Request Test Coverage Report for Build 613559196Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
It was not intended to add a new composable with #5537. I'm closing for now - likely |
} | ||
}; | ||
|
||
const updateNewsletterData = async (newsletter): Promise<NewsletterSections> => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updateNewsletterData
name is redundant because it's already is part of useNewsletter
. I suggest naming it just update
to match load
method.
export interface UseNewsletterFactoryParams extends FactoryParams { | ||
updateNewsletterData: ( | ||
context: Context, | ||
params: NewsletterSections) => Promise<NewsletterSections>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
) => Promise<NewsletterSections>;
should go to the next line
description: 'create update newsletter sections functionality', | ||
link: 'https://github.com/vuestorefront/vue-storefront/issues/5537', | ||
isBreaking: true, | ||
breakingChanges: [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
useNewsletter
composable is not BC, because it's totally new composable. However, changes in MyNewsletter.vue
that require a new component that uses new composable is BC :)
{
{
module: 'core / commercetools',
before: '',
after: 'Added newsletter functionality',
comment: 'Added \'useNewsletter\' composable and \'components/MyAccount/NewsletterForm.vue\' component, modified \'pages/MyAccount/MyNewsletter.vue\' component'
}
}
export interface NewsletterSections { | ||
woman: boolean, | ||
man: boolean, | ||
kids: boolean, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't hardcode Newsletter options.
export interface UseNewsletter { | ||
newsletter: ComputedProperty<NewsletterSections>; | ||
loading: ComputedProperty<boolean>; | ||
error: ComputedProperty<UseNewsletterErrors>; | ||
updateNewsletterData: (params: NewsletterSections) => Promise<NewsletterSections>; | ||
load: () => Promise<NewsletterSections>; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see few issues here:
- Response from the API saved in the
newsletter
property will be different for every integration, so we cannot assume any signature. We need TypeScript's generic here, likeNEWSLETTER
. - We don't return any values from the
load
orupdate
methods in any other composable, so to be consistent, both should returnPromise<void>
. - We don't know what properties might be needed in
update
method. I would suggest using generic here, likeNEWSLETTER_UPDATE_PARAMS
.
export interface UseNewsletter<NEWSLETTER, NEWSLETTER_UPDATE_PARAMS> {
newsletter: ComputedProperty<NEWSLETTER>;
loading: ComputedProperty<boolean>;
error: ComputedProperty<UseNewsletterErrors>;
updateNewsletterData: (params: NEWSLETTER_UPDATE_PARAMS) => Promise<void>;
load: () => Promise<void>;
}
newsletterRef.value = await _factoryParams.updateNewsletterData(newsletter); | ||
return newsletterRef.value; | ||
} catch (err) { | ||
error.value = err; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
error.value.update = err;
try { | ||
const data = await updateNewsletterData(newsletter); | ||
await onComplete(data); | ||
} catch (error) { | ||
onError(error); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, the code you referred to is outdated. We no longer throw errors from methods. To check if the request was successful, refer to the error
object from useNewsletter
.
|
||
const loadedNewsletter = await load({}); | ||
|
||
expect(loadedNewsletter).toStrictEqual(defaultNewsletterData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here you use toStrictEqual
, but below you use toMatchObject
. If both are used for the same purpose, I'd suggest using toMatchObject
because it better describes what we are expecting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally, as load
shouldn't return any data, we should be comparing defautNewsletterData
and newsletter
object from useNewsletter
composable.
@@ -0,0 +1,103 @@ | |||
<template> | |||
<form | |||
id="newsletter-form" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are not using this anywhere, so it may be removed
<div class="form__checkbox-group"> | ||
<SfCheckbox | ||
v-model="newsletter.woman" | ||
@change="updateNewsletterField('woman', newsletter.woman)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it will change anything. Should we use !newsletter.woman
or $event
's value?
Related Issues
closes #5537
Short Description and Why It's Useful
This pull request implements functionality for updating newsletter sections. For now it's just a mock (similarly to user billing), so after page reload checked checkboxes won't be checked. However, if the user navigates the pages/sections, the checkboxes will remain checked.
Screenshots of Visual Changes before/after (if There Are Any)
Which Environment This Relates To
Check your case. In case of any doubts please read about Release Cycle
develop
branch and want to merge it back todevelop
release
branch and want to merge it back torelease
hotfix
ormaster
branch and want to merge it back tohotfix
Upgrade Notes and Changelog
.js
file with information about my Pull RequestIMPORTANT NOTICE
CHANGELOG.md
with description of your changeContribution and Currently Important Rules Acceptance