Hi, I'm doing research into snapshot testing of React components and have some questions about your decisions regarding this kind of testing. I think this is the right channel for this topic :)
I noticed in reaction-next-starterkit, there are tests for almost all of your React components, most of which use snapshot testing exclusively.
Most of these tests are smoke tests that take a snapshot of the "basic" component and asserts it matches the existing snapshot.
For example: https://github.com/reactioncommerce/reaction-next-starterkit/blob/master/src/components/Link/Anchor.test.js
A few questions regarding these tests:
Regarding more specific snapshot tests:
See here: https://github.com/reactioncommerce/reaction-next-starterkit/blob/master/src/components/ProductDetailInfo/ProductDetailInfo.test.js
I've come across some blog posts that outline some cons of snapshot testing and wondered if you may give some insight from your experiences.
See section on “The ‘it renders’ test”, I think it relates the most to reaction's approach.
“First, I would suggest that you do not want to replace your smoke tests with snapshot testing.”
“The problem is that every time you edit the component you will unintentionally break your snapshot test. This leads to you being habituated to blindly accepting new snapshots; because there would be so many false positives. At this point, you have defeated any benefit that snapshot testing provides and added an extra bit of work every time you edit a component.”
I find these to be valid points but I somehow feel snapshot testing can have its place with React components. I’m trying to find that balance.
Hi guys, i see the exciting next release on the roadmap
i have also seen the perf updates video https://www.youtube.com/watch?v=ySqPjX6DICE
w/c i remember august being mentioned as the target for next release. May I ask the status of the next release? is there some board that we can check to see updates?
Does the graphl server currently provide mutations to create/update products?
Looking at the code it seemed to me that the only mutation regarding this currently is
publishProductsToCatalog, which gets Products from Products collection and publishes them to Catalog.
Is a mutation to create Products in progress already?
For a project I need to find an API driven way to create and update products using an external inventory management that triggers these changes.
Im still quite new to graphQL and wonder if this is the way to go/the current implementation in /plugins/core would serve as a good starting point
Thanks for your Feedback. What I wondered was, if I could essentially skip the product collection, and directly publish to catalog, but that probably won't work as (didn't actually check that ) other server functions, like add to cart, are still reliant on the products collection to get the data.
I believe in 1.13 users got the Catalog collection as publication for Products, and logged in admin users got the "real" Products.
Therefore, a normal user could navigate the shop products without actual entries in the Products collection.
It seems like this was changed again in 1.15 with the integration of apollo to fetch the product grid, which also makes sense.
For my graphql createProduct mutation schema i want to go the way the catalog did when feeding the mutation, with options and variants being children of the top Product, so it can all fit into one mutation.
But something doesn't feel right about this:
Probably still the way to go for now.
But from a logical point of view, could it be open for discussion if the reaction server functions should also work with Catalog instead of Products?
As products resembleskind of an internal inventory, which could then also be swapped out with an external, like in my case.
productVariantId. Does that mean that it must be from the Reaction Product collection? We have Orders work going on at the moment. I’ll discuss this with the team so we’re aware and can continue decoupling on the Orders side of things, too.
ApolloProvider and oneappWithTranslation
from next-18next, try changing the order soApolloProvider
simple:rest-accounts-password& see the token being return, but still clueless where exactly the authentication is taken place in the code