sap / spartacus Goto Github PK
View Code? Open in Web Editor NEWSpartacus is a lean, Angular-based JavaScript storefront for SAP Commerce Cloud that communicates exclusively through the Commerce REST API.
License: Apache License 2.0
Spartacus is a lean, Angular-based JavaScript storefront for SAP Commerce Cloud that communicates exclusively through the Commerce REST API.
License: Apache License 2.0
This ticket is to regression test all facades.
Documentation is #416.
Original master description:
While we're using ngrx store inside, we like customers to not necessarily be bother with the complexity of ngrx. Moreover, we might want to move (partially) to other state management solutions in the future. We've already started to build a facade layer on top of ngrx store, and must finalise this for all ngrx services.
Spike was done as part of #140. Tobias and Wei working on it and probably done eod Nov 1.
It can be used as an example for the facade (but not the move).
Task: Add any negative tests to Added to Cart Modal. Either as functional, integration, unit test.
For example:
Use your imagination :)
Please note pull request [https://stash.hybris.com/projects/C3PO/repos/spaccelerator/pull-requests/122] doesn't include any sort of negative tests.
See definition of done
Tasks related to the general Account Profile page: name, password, email, consent.
Tasks realted to implementing accessibility.
The storefronts is driven by different content streams. Most of the content is driven by either the CMS or by the product content. There's however a portion of content that is provided by so-called site labels.
Site labels are in the current storefront solution (spring mvc based) based on java resource bundles, which gives some issues:
There's a lot of room for improvement. We like to setup a solution that provides:
Angular doesn't provide these features yet, but have hired the author of translate to build this is as a standard feature in Angular. This takes longer then expected and it's recommended to start embracing ng-translate so that we can relatively smoothly transition to the standard solution (probably beyond ng7 and in parallel with ngyvi).
(Using backend dev-com2 and just-registered user without any addresses added before):
When a user goes to checkout (address form) and refreshes, then after reload there are many errors in console of the same type:
{code:java}
ERROR TypeError: Cannot read property 'childs' of undefined (NavigationComponent.html:2){code}
For runtime performance reasons we need to move into an architecture where different parts of the application are lazy loaded. Angular provides lazy loading out of the box, however the lazy loaded elements are driven by the router. The router is typically related to "pages". This works well in case the page content is determined during design time, so that the code can be split up at build time. But with CMS driven pages, where the page content is composed at runtime, this technique doesn't fly. A smarter approach is required to allow for a good mix of CMS driven pages and lazy-loaded techniques.
We basically need to lazy load components. The granularity can be decided, but CMS components should be lazy loaded (although a few of them could be bundled together) as they can be added to any CMS page at any time.
Some things to keep in mind:
A number of areas in the storefront is driven by configuration. The commerce backend API (baseUrl
) is good example. Angular-cli provides a mechanism for different configurations per environment, but at the end of the day, the configured baseUrl is baked into the JS code. This means that the application cannot be deployed to various environments (dev, qa, prod); a new build is required for each and every environment. The same is true for the pipeline; the pipeline's backend must be aligned with the baked in configuration.
When we deploy the JS app on a server, ideally, the server should provide a configuration to the JS app when it's served. Dev-ops can than reconfigure the backend baseUrl, and with the next request, the JS app will interact with the newly given baseUrl.
There are different possible solutions, none of them are standard (not in angular(-cli) nor in JS world).
There a number of things we try to achieve/ avoid:
Based on this, we envision:
The storefront looks for meta-tag with a specific name, indicating the commerce backend base URL
<meta name="occ-backend-base-url" content="https://localhost:9002" >
If the meta tag is not available (can be empty though), the config will fallback to configuration (what we have today). Customers can decide to configure the baseUrl or use a proxy to reroute the request.
This architecture should be reused for other configurations, such as other backends.
Looks like Roman did changes to styling too.
This ticket is to make sure Roman got them all, otherwise move back to PO column.
Github issue to change prefixes in code: #42
Previous internal ticket: SPA-1220
test issue for accepting cla
Bill created CONTRIBUTING.md for early October; Wei did a preliminary review (see SPA-1367) and I made updates.
We need all developers to study and provide feedback to ensure the process reflect our working model and improves efficiency.
Test adding different quantities. (1,2,3) and assess that there is a correct number difference on the minicart.
Test the different operations the user can do from the add to cart modal
-- change qty
-- close
-- view cart
-- procede to checkout
Asses that the following are as expected:
-- title.
-- ID
-- Price
-- Short desc
-- stock level
-- pictures
-- Tabs have the expected content:
--- Product details
--- Specs
--- Shipping
--- Reviews
---- Assess that we can submit a review without an error (and ideally asses that the review displays. May depend on the default backend settings, reviews need to be approved in backoffice before thay are displayed )
The code base has grown lately and a bit of clean structure is missing. We like to improve this with 2 changes:
Split up libraries
Currently the storefront is implemented in two main libraries: storefront and styles. In order to scale better and separate out the framework bits and UI components, we need to separate those out over 2 libraries. Other storefront dev teams (i.e. telco, fsa) can then start building their own UI component lib with a dependency on the core lib only.
The tasks foreseen for this epic are:
core
seems to be the right name)Reorganize UI components
TBD
General epic for adding missing E2E and unit tests. For new features, these are part of DoD.
Improve the current product search e2e test: https://stash.hybris.com/projects/C3PO/repos/spaccelerator/browse/projects/storefrontapp-e2e/src/suites/product-search.e2e-spec.ts
EDIT: github link: https://github.com/SAP/cloud-commerce-spartacus-storefront/blob/develop/projects/storefrontapp-e2e/src/suites/product-search.e2e-spec.ts
We should cover:
Search listings: Facet UI unit tests
We can provide an angular schematic to simplify the creation of custom components, routes, page templates, etc. This will help to:
Angular schematics are the technique that can be used for this.
In SPA-850, we added fired promotions to cart. For some reason, potential promotions aren't appearing. Creating this ticket and assigning to Bill to talk with promotions team and figure out where that data is.
We like to fully adapt CSS custom properties in order to:
We've experimented with this approach in https://github.com/tobi-or-not-tobi/lipstick-css and the recent decision to drop Internet Explorer 11 has strengthen our decision here (no need for fallbacks).
This is an important input in our rework on the UI framework, see #10.
The readme's are already pointing to https://stackoverflow.com/questions/tagged/spartacus-storefront but we don't yet have the tag.
While the complete storefront can be added in one go by using the cx-storefront
component, customer sometimes use the commerce storefront partially. Some customer would only use the checkout flow, and have other areas of the storefront being rendered in a separate system.
We need to validate and most probably rework the organisation of our storefront:
Also #1153
Currently our UI framework of choice has polluted all UI components. This is bad for customers who do not or cannot use bootstrap. We want our UI layer to be independent on a specific UI framework. Moreover, we should avoid a mandatory peer dependencies like bootstrap and ng-bootstrap.
This requires a number of poc's (such as https://github.com/tobi-or-not-tobi/agnos) and rework.
The goal of this work is:
With Agnos I've learned that SASS is a great choice for UI framework agnostic approach:
But, we're open to other approaches.
An alternative approach is obviously a design system. ng-bootstrap is an example of this, but there are big hesitations with this:
Page templates control the overal layout of a page and can be selected by business users in the CMS. Our storefront UI must have a clean list of page template components, which only represent a CMS page templates from the backend. The current implementation has a number of issues:
For other E2E tests, we decided to focus on where backend adds value or can influence or cause breakage.
The assumption is that these kinds of tests are in addition to what Stan already is working on, so check with him. E.g. you can register successfully, and the user is logged in.
For E2E purposes, some suggestions related to how we get data from the backend:
Product details page is a good one to make assertions from, as well as registration page for forms.
The backend sampledata provides English, German, Chinese and Japanese.
Note that language and currency e2e tests are similar in scope - see SPA-945.
While the architecture is completely driven to allow for upgradability, there will be breaking changes from one version to another that wil make upgrades less seamless as we'd like. Also, dependency management can cause a lot of time for app developers for each and every (larger) release that we bring. Therefor we like to use angular schematics to allow for a seamless upgrade of dependencies and other breaking changes we might do.
When we moved Spartacus to open source, we concentrated on 1808.
The instructions are similar but not the same for 1811, so would be good to make a copy and label them 1808 and 1811 respectively.
Some things I know so far:
Come up with a mechanism to release our libraries to npm from Travis CI using a specific set of branches or tags
While our commerce backend is really strong with multi-site capabilities, this has not yet land fully in the Spartacus storefront. We already support multi-site with a configuration property, but the true multi-site features require:
We need to introduce type safety on a lot of layers, but at least on the facade layer (#6). We've already generated types from out OCC backend (using swagger.json and a standard generator), and ideally we use those generated types.
Type safety provides static code validation and helps customers to develop faster.
The route configuration requires several enhancements:
The contributions document mentions the CLA.
"Contributor License Agreement" section
What's not clear is that you don't need to 'sign' the CLA until you make your first PR.
The PR status page will list all the things that have to happen to accept the PR:
If CLA is not signed, there is a link to do so. Only then does the spartacus repo show up in that menu in cla-assistant.io.
Separate ticket for styling: #43.
Previous internal ticket: SPA-1218
Main selector was changed in: SPA-1219
To reproduce:
Epic for topics related to address management page
We've started a mock server implementation, using json-server and faker.js. The goal of this mock server is to be up and running for devs so that they can start right away without being dependent on a commerce backend. (no commerce backend required). Other advantages are around mocking unit tests, e2e testing, and implementing new features for those areas where there's not yet a backend ready.
Currently the mock data can be generated for a commerce backend. The sample data is outdated, and this is the main thing we like to fix in this epic:
In addition, we need to publish the mock/sample data in an npm package, so that it can be versioned and pulled for projects.
We might want to do this with the following approach:
This approach gives a number of advantages:
In angular we don't use the class element IDs and therefor we can't do:
<label for="FORM_CONTROL_ID">label text</label>
<input id="FORM_CONTROL_ID">
Instead, we should ideally do:
<label>
label text
<input>
</label>
This is both a fix as well as a simplification.
This should be fixed in the various forms we have (login, address forms, checkout, etc.)
For each time we release on github, we need to include a change log that lists the changes that belong to the release. Here's an example:
https://github.com/angular/angular-cli/releases
And here's the angular script that generates it:
https://github.com/angular/angular-cli/blob/master/scripts/changelog.ts
For other E2E tests, we decided to focus on where backend adds value or can influence or cause breakage.
The assumption is that these kinds of tests are in addition to what Stan already is working on, so check with him. E.g. you can register successfully, and the user is logged in.
For E2E purposes, some suggestions:
Check that the menu is there and populated (even if there is only 1 currency right now it's still there I think)
Changing the currency refreshes pricing only
** ...but stay on same page/view/screen.
** In fact if you are in the middle of checking out, adding an address in a form, and change the currency, your entire form should remain the same.
Product details page is a good one to make assertions from. Check that prices updated to expect new amounts. But also, a checkout form like shipping address to ensure the user's data isn't erased.
Also: do a browser refresh after switching the currency/language, to make sure the change sticks beyond the explicit change request from the user. (and doesn;t fall immediately back to the default).
The backend sample data has US dollars and Japanese Yen,
Note that language and currency e2e tests are similar in scope - see SPA-944.
This ticket is for implementing the customer's Payment Management page.
We need to add cms in the backend but you can use page label for order history in the meantime.
Display cards of existing addresses, like checkout
https://98qkkl.axshare.com/#g=1&p=addresses_added
Display empty form by default
https://98qkkl.axshare.com/#g=1&p=spa-179-addresses_empty
Clicking Delete displays "are you sure" inside the box
https://98qkkl.axshare.com/#g=1&p=addresses_delete
Clicking "Set as default" sets the address as default, and it moves to first spot.
Confirmation message appears at top.
https://98qkkl.axshare.com/#g=1&p=addresses_setasdefault
Clicking Add shows the form with fields blanked with intro text "Add a new shipping address."
Like: https://98qkkl.axshare.com/#g=1&p=spa-179-addresses_empty
Remember the country/state thing in checkout, same thing.
For default country, use same country as the user's default address (if there is one).
Otherwise use same behavior as checkout.
Clicking Edit shows the form with fields filled in, with intro text "Edit an existing shipping address."
Like: https://98qkkl.axshare.com/#g=1&p=spa-179-addresses_empty
but with info.
Ignore the wire https://98qkkl.axshare.com/#g=1&p=addresses_addform, it's a bit weird.
Don't forget that if there are no state/regions for a country, hide the state/region menu.
The backend will give an error if you supply an invalid state/region code, but is ok if there is none at all.
Copy what we have in checkout.
Trigger address verification when user clicks Save.
Clicking cancel drops the changes and goes back to the list.
This ticket is for implementing the customer's Account Profile page.
We need to add cms in the backend (SPA-1416) but you can use page label for order history in the meantime.
Wires are: https://98qkkl.axshare.com/#g=1&p=spa-143-_profile
but waiting to hear if they are final.
Tasks (can be split into separate issues, use epic profilepageimpl):
The new Account page combines items that were separate pages in Accelerator: changing name, email, password, or consent preferences, as well as closing your account.
For other E2E tests, we decided to focus on where backend adds value or can influence or cause breakage.
The assumption is that these kinds of tests are in addition to what Stan already is working on, so check with him. E.g. you can register successfully, and the user is logged in.
h2. 1. Error situation + check what happens when user tries to register with existing username
h2. T&C link
h2. Cart merging tests that aren’t in big e2e test
The following would be Angular unit tests as they don't touch the backend.
For other E2E tests, we decided to focus on where backend adds value or can influence or cause breakage.
The assumption is that these kinds of tests are in addition to what Stan already is working on, so check with him. E.g. you can register successfully, and the user is logged in.
Make sure not to redo what was already done with the big happy path that stan did, but here are some E2E cart ideas.
Is the following implemented? If not create a spa ticket for future.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.