These are chat archives for reactioncommerce/reaction

23rd
Feb 2019
Dileepa
@dileepab
Feb 23 06:05
Hi. Can i add new currencies to Reaction ?
If yes, How can i add LKR (Sri Lankan Rupees)
Thank you.
Janus Reith
@janus-reith
Feb 23 08:43
Under locales.countries, Sri Lanka is already referenced to a currency LKR
You will probably just have to add an entry LKR under currencies, similar to the ones that are already there
Loan Laux
@loan-laux
Feb 23 08:48
@janus-reith I was about to recommend Meteor settings, but you ruled that one out. However, have you considered the fact that you can pass Meteor settings as an env variable?
Janus Reith
@janus-reith
Feb 23 08:50

I actually went with meteor settings in the end, altough it looks weird:

SENTRY_HOST_URL: 123
SENTRY_SERVER_URL: 123

and then METEOR_SETTINGS: '{"public": { "SENTRY_CLIENT_URL": 123 }}'
But what really bugs me is using it in development.
I have to create a settings.json and then need to modify the docker compose file to use that settings file.
A weird "feature" of Meteor to enforce that, explaining it is because setting files could be reactive. <-- Yeah thank you, but I'll probably have my reasons when I still put in an ENV var
Janus Reith
@janus-reith
Feb 23 09:02
This could probably be worked around in docker with a custom command for that service that checks if METEOR_SETTINGS is present and if, writes that to a json in the container and passes it to meteor then, but won't be worth the effort I guess
Dileepa
@dileepab
Feb 23 09:41
@janus-reith Thanks. It works. :)
Nuruddin Badawi
@NuruddinBadawi
Feb 23 09:59
Hi, Should I need to create a new query to get all shops, or it's available in reaction?
Loan Laux
@loan-laux
Feb 23 10:03
@NuruddinBadawi AFAIK, there is none. Clients should know their shop ID when performing queries, which is why there has been no need for that until now. However, if you do need it, you can absolutely implement it yourself.
@janus-reith Re: use in development — a recent PR to Reaction removed OOB support for settings.json files if I remember correctly. So a bit more tinkering to do to get it to work. I guess leaning on Meteor-specific mechanisms like these isn't really recommended right now given the switch in direction. May I ask why you need these to be passed to the :3000 front-end and don't want to do it programatically?
Janus Reith
@janus-reith
Feb 23 10:13

@loan-laux Yes that particular PR wouldnt solve it, as it still relies on an external json file.

Nedds to be on the frontend as the var needs to be available to the client ASAP.

I first tried passing it with a Meteor DDP Call during Meteor.startup on client and server, but that was too late.
I created multipe errors to test with, one of them was a test route that would directly throw an Error.

If the entrypoint was a different route and I would navigate to my test route, errors would be logged properly.
But if that test route was my entry point, it would fail before Sentry was initialized.
Therefore i can't rely on a DDP connection and GraphQL woul probably be the same case.
The reason I used Meteor DDP at all was that I hoped that some Meteor magic in startup( ) could serve this earlier.

Nuruddin Badawi
@NuruddinBadawi
Feb 23 10:16
@loan-laux I’m traying to make the marketpalce public for all, and you can see all shop available and navigate between them to see poducts in each on, so this needs to bring all shop and make route for single shop, right?
Nuruddin Badawi
@NuruddinBadawi
Feb 23 11:01
It seems the storefront show just the primary shop products,
I switch the classic reaction to the marketplace, and I create a new shop with dummy products,
I can’t see it in the storefront, and also this URL shop/:slug not work like in the back-end
so is it normal behavior or a bug?
Loan Laux
@loan-laux
Feb 23 11:23
Ah, got it @janus-reith. But what about storing these variables in reaction/.env + creating a GraphQL query and storing it in local storage for the rest of the user's session?
Also, why would you want to make this plugin compatible with the old Meteor storefront instead of the Next.js one? Is it to fit an existing project that's running on the Meteor storefront?
@NuruddinBadawi By default, the Next.js starter-kit does show only the primary shop's products. It's intended to work as a multi-site setup rather than a full all-in-one marketplace out of the box. Right now, the Next.js storefront queries for the primary shop ID and uses that shopId for all queries throughout the navigation. That was done to simplify onboarding for single-shop use cases, but you can absolutely skip that part and simply use whatever shopId you'd like (typically the shop's URL).
Nuruddin Badawi
@NuruddinBadawi
Feb 23 11:31
@loan-laux you mean by shops URL this ? /shop/:slug ?
as I understands meybe it’s wrong, now the next storefront just for single shop, so If I have marketplace that’s mean I need setup storefront for each shop, right ?
Nuruddin Badawi
@NuruddinBadawi
Feb 23 11:36
and regireding to primary shop’s, can I have more primary shop’s and how to make shop primary?
sorry for asking a lot.
Loan Laux
@loan-laux
Feb 23 11:38
No, I mean having multiple domains pointing to the same storefront. Like shop1.yourdomain.com and shop2.yourdomain.com, or even two different domains like somebrand.com and someotherbrand.com. And then you pass the request URL as the shop slug, which will have to match with a shop record in your DB, and the relevant catalog will be shown.
Janus Reith
@janus-reith
Feb 23 11:44
@loan-laux Well, on the one hand, yes, it should run on existing instances. Also, dont forget that the whole Admin UI is also still part of the meteor application. Errors there should be logged aswell.
Regarding the GraphQL query, the issue would probably be the same like it is with a Meteor DDP connection.
If there is an error on the entry point, it will happen before any callback ran to deliver that var to users.
Loan Laux
@loan-laux
Feb 23 11:45
Ah, yeah, you're right. But wouldn't you have a corresponding server-side error for these scenarios? Like for a 404 or a 500, you'll ultimately have a trace of that on the back-end. Or maybe I'm missing some other use case?
Janus Reith
@janus-reith
Feb 23 12:13
No, I would not.
This is about the client side js exceptions that could occur
Loan Laux
@loan-laux
Feb 23 12:15
Alright, got it. Then yes it's a bit tricky. Maybe pass it as an HTTP header?
Janus Reith
@janus-reith
Feb 23 12:15
Beside typical errors that could occur, also keep in mind that JS interpretetation varies between browser engines.
hm
Probably would need to modify core code for that
Loan Laux
@loan-laux
Feb 23 12:17
Then I guess it would make for a great PR, because we should be able to pass custom headers if needed
I think we identified a need for a new feature here
Janus Reith
@janus-reith
Feb 23 12:21
What I just wondered: I never tried to parse the respone header in a client that just recieved said response - wonder how to do that