Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Gustavo Jiménez
    @gustavjf

    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:

    1. What are you trying to solve by writing snapshot tests for your components?
    2. What value do you get out of a test that checks its "basic" render? (a very broad, general snapshot case as opposed to a specific case with assertions, i.e., XYZ tag exists)
    3. How do you deal with false negatives for that test every time the component is changed? Has this caused problems for you so far?
    4. When do you decide to use snapshots over "classic" assertions in your component tests? Why?

    Regarding more specific snapshot tests:
    See here: https://github.com/reactioncommerce/reaction-next-starterkit/blob/master/src/components/ProductDetailInfo/ProductDetailInfo.test.js

    1. Why did you choose to use snapshots for these specific tests instead of directly asserting the price/description content exists after rendering?

    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.

    For example:

    1. https://engineering.ezcater.com/the-case-against-react-snapshot-testing

    See section on “The ‘it renders’ test”, I think it relates the most to reaction's approach.

    1. https://medium.com/@ntgard/jest-snapshot-testing-the-bad-parts-c93aca187ba5

    “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.

    Thanks!

    Janus Reith
    @janus-reith
    What is the current roadmap regarding the reaction next.js based storefront when it's finished?
    Will it offer admin functionality, like editiing products, or is the plan to still run meteor separately to provide shop admin functionality?
    Brent Hoover
    @zenweasel
    The end goal is to remove Meteor completely, but right now the storefront is going to be focused on consumer-facing. Probably more likely that even when Meteor is removed it may be a separate app
    Theo
    @shierro

    Hi guys, i see the exciting next release on the roadmap
    https://www.reactioncommerce.com/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?

    Janus Reith
    @janus-reith

    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

    Brent Hoover
    @zenweasel
    I don’t believe it currently does. The focus for now has been on the consumer-facing app, so essentially just read-only for products
    Janus Reith
    @janus-reith
    Will the current products -> catalog publication system be kept on the long term, or is this just to provide backward-compatibility?
    As I'm evaluating an api-driven Reaction shop, where the external inventory adds the products, I wonder If i should directly publish to catalog, or go the route of adding it to products, then publishing to Catalog, like when it is manually created.
    Ticean Bennett
    @ticean
    Hi @janus-reith, a see I'm a late on answering this but I just saw your question and wanted to give you some info. The catalog is here to stay. The catalog publication system will be around for the long term, too - at least in spirit.
    The idea of the catalog is to decouple the product definition (and the process that goes along with that) from the display catalog. We get a lot of benefits from that. A good one is that the storefront is faster.
    For now, we do the publishing directly in the main Meteor process by directly writing to the catalog collection, but we're planning to decouple that even further and publish the catalog data via a messaging bus. This will truly decouple the catalog from products.
    Ticean Bennett
    @ticean
    Then you could define the products in Reaction's products system and publish to catalog. Or publish them from somewhere else, similar to the scenario you're investigating. The source won't matter so long as the published messages conform the catalog data schema.
    Ticean Bennett
    @ticean
    Hopefully that's not too far off in the future but I can't give a timeline. For today, there may be some evolution of the catalog but we won't take it away.
    Janus Reith
    @janus-reith

    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:

    1. Mutation recieves product data, creates document in Products collection.
    2. Iterates over variants/options and creates further documents for them.
    3. Calls publishtoCatalog with the id of the new main product, to create a document in Catalog including all children, which essentialy resembles the data we had initially when the muation was called.

    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.

    Ticean Bennett
    @ticean
    Great feedback, @janus-reith. The design we’re working toward is that you could skip the product collection. There may be limitations at the moment that would prevent that as we’re trying to release changes incrementally. I don’t think anyone's tested a complete removal, yet. But I think we’ll get there soon. Please share any notes if it you try it out yourself.
    Ticean Bennett
    @ticean
    Recent changes to the Cart have changed the items from Products to CartItems, which are an abstraction of the “things” in the cart. CartItem has enough data for display in the Cart UI and for the creation of Orders. It does have a ProductConfiguration attribute that includes productId and 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.
    Very much welcome your feedback and suggestions as you think through how this would ideally work in your scenario.
    Janus Reith
    @janus-reith
    Thanks, that is good to hear!
    ereyes97
    @ereyes97
    Hello, I would like know more about how reaction commerce imports a plugging. Where I can find documentation about it or what part of the code is dealing with it.
    I believe that part is not include in meteor own features...
    Matteo Sanna
    @matteosanna_gitlab
    Hello, I would like to add a Language selector on my storefront header but I cannot retrieve available languages from shop.gql . Any of you could help me? Thank you in advance.
    Eliot Hills
    @elhil
    @matteosanna_gitlab I think you’ll get more help in the reaction room
    Janus Reith
    @janus-reith
    I wonder if it would be feasible to separate the Operator from the GraphQL API somehow and put it under Apache-2.0 aswell?
    Janus Reith
    @janus-reith
    As I wonder how the legal obligations are here. API seems to be ok so far under GPL-3.0, and the Starterkit being Apache-2.0 is helpful aswell.
    But if a third party would have access to the Operator UI, they would run the client side code on their computer.
    While this shouldn't be too harmful as this would just affect the client side js part, it could still scare away enterprise users that might want to implement a lot of custom business logic into the operator dashboard.
    Thoughts?
    Eliot Hills
    @elhil
    @janus-reith I wholeheartedly agree with this idea
    Janus Reith
    @janus-reith
    I think about implementing e2e test with cypress: https://www.cypress.io/ From what I read it really seems awesome
    However I wonder if it would make more sense to do these individually for the nextjs starterkit and reaction meteor backend / operator, or if it would make more sense to completely decouple it into a separate repo that tests both, as for the e2e tests I would need both
    Janus Reith
    @janus-reith
    I`m thinking of implementing a way to track admin/shop manager user actions.
    e.g. user xyz added field a to product 132
    Ultimately it would be great to have a visual representation of that in the dashboard and to allow revert actions
    DiegoAAG
    @DiegoAAG
    Hello guys!
    I'm new here, i've been studying reaction for the last few days and now I'm in the multi-shop and marketplace docs and i have some doubts when it comes to multi-tenant architecture.
    I'm developing an ecommerce solution where we would like to create a new tenant for every new shop, customize the shop for his own needs, and stuff like that.
    I've seen some discussion about multi-tenants in 2015 threads and some updates about some multi tenant features, like multi-tenant shipments. And for what I've read reaction was created to support multi-tenant from the start. Does Reaction already support a tenant per domain/shop architecture?
    DiegoAAG
    @DiegoAAG
    Someone please?
    Janus Reith
    @janus-reith

    d

    thabungm
    @thabungm
    Hi well wishers!
    I'm a reaction newbie, kudos to the community.. I am deciding to use reaction for my project. Inside the plugin/server folder I see no-meteor folder, I know this is meant for graphQL, my question is, does reaction provide 2 ways of development meteor based and graphQL based? are they related?
    Karbal
    @karbal
    Important: there is no button to approve the payment in detail of the order, and payment remains on not to capture
    for Storefront NextI18Next doesn't work with apollo Context
    Karbal
    @karbal
    @/all Thanks
    Janus Reith
    @janus-reith
    @karbal Not sure what exactly doesn't work with NextI18Next for you, but I can confirm that integrating NextI18Next works for me as expected.
    If you experience errors due to having multiple HOCs where one is ApolloProvider and oneappWithTranslationfrom next-18next, try changing the order soApolloProvider wrapsappWithTranslation `
    thabungm
    @thabungm
    sorry in advance for a stupid Q, I am trying to understand authentication, went through.. my understanding so far is meteor is handling the authentication & not graphQL, & I have installed simple:rest-accounts-password & see the token being return, but still clueless where exactly the authentication is taken place in the code
    Adi Vemuru
    @vemuruadi
    @thabungm I'm in the same boat, will let you know when I find it. I'm trying RC to support 2 user types (Students, Teachers) and custom registration/login UI too. will share my observations.
    thabungm
    @thabungm
    @vemuruadi thanks mate..
    Tapas Mahanta
    @tapas100
    Hello folks i am also new to reaction , after migrated from meteor rest API to graphQL , i am having trouble understanding the API docs like "How to create a product using graphQL". Please anyone has done this , let me know
    Gonçalo Martins Ribeiro
    @gmartinsribeiro
    Hello everyone! I'm having the same trouble as @tapas100 . I've found the mutation for publishProductsToCatalog but there's none for createCatalogProduct. Can you help?
    Alvaro Bueno
    @delagroove
    @thabungm if you see the developer roadmap there’s still meteor around, but you should aim for developing mostly in graphql, in my experience the meteor part can be referenced from other modules.
    Phuong Nguyen
    @neunygph
    Hello I’m new to Reaction , can we run Reaction store front on a cloud server such as AWS EC2 instead of Docker?
    Also is Reaction production ready?
    Gonçalo Martins Ribeiro
    @gmartinsribeiro
    yes and yes :)
    you can also use it on EC2 and using docker as well
    I'm running it on AWS ECS
    gustavoca
    @gustavoca
    hello guys, do you know what would be the min requirements in terms of cpu and ram for the storefront-example?
    mohamm4d
    @mohamm4d
    Hello guys , do you know any project done by Reaction with very large stock and huge number of vendors ? I would appreciate if anybody let me know .