These are chat archives for reactioncommerce/reaction

30th
Dec 2014
Michael Jenny
@prinzdezibel
Dec 30 2014 19:46
@aaronjudd Hi. Are the settings in dev.sample.json not available at runtime?
Meteor.settings is undefined, even if I list the setting under "public"
Aaron Judd
@aaronjudd
Dec 30 2014 21:06
@prinzdezibel those are available at all times, which one in particular where you looking for?
of course, you will only see settings from “public” when you “view source” if that’s what you mean
if you are trying to use a variable from there it should be available at “Meteor.settings.xxx"
Michael Jenny
@prinzdezibel
Dec 30 2014 21:08
I'd like to have a new one like "CHECKOUT_WITHOUT_USER_ACCOUNT" and check on it in a template helper. But that's not working because Meteor.settings is undefined..
Beside that.. How would you do it?
I have not started with --settings though.
Is that necessary?
Aaron Judd
@aaronjudd
Dec 30 2014 21:12
Meteor.settings is always defined. It should be a simple as “Meteor.settings.GUESTCHECKOUT=true” in a startup file. If you don’t start with —setttings settings/dev.sample.json” (or whatever) then it won’t be defined
you’ll find that I have always defined the “default” settings variables in code, and the—settings are just defining them / overwriting them
so it’s either a) define in code and settings.json is backup, or always require settings.json. I always define in code, because not all environments support startup with settings.json (when you run as a compiled app after doing a meteor build)
Aaron Judd
@aaronjudd
Dec 30 2014 21:18
also if you want to use as a ENV variable you need to define that as well. Typically I add these to fixtures.coffee file
CHECKOUT_WITHOUT_USER_ACCOUNT = Meteor.settings.CHECKOUT_WITHOUT_USER_ACCOUNT || process.env.CHECKOUT_WITHOUT_USER_ACCOUNT || false
one last thought, remember the load order as well (alphabetical, in app, or defined in package.js in packages)
Michael Jenny
@prinzdezibel
Dec 30 2014 21:23
thank you
TJ Mapes
@tjmapes
Dec 30 2014 21:26
I just recently heard about reaction and think its very promising. Any thoughts as to when a stable 1.0 would be available?
Aaron Judd
@aaronjudd
Dec 30 2014 21:28
@tjmapes not sure about a 1.0, but we’re shooting to have a “stable” production ready beta by June 2015. There’s a lot there now, but there’s a lot on the roadmap to still be done, mostly in the order workflow.
TJ Mapes
@tjmapes
Dec 30 2014 21:29
@aaronjudd thats great to hear. I'm going to be doing a re-platform in 2015 and was looking for some new open source ecommerce solutions
Aaron Judd
@aaronjudd
Dec 30 2014 21:29
before the holidays hit, we were working on a more public, detailed, roadmap. I think that should be published in the next couple of weeks, depending on when everyone gets back to work ;-)
TJ Mapes
@tjmapes
Dec 30 2014 21:30
Not sure I'll be waiting until June, but this is exciting. If you have any work that needs to be done on a front-end level, let me know :)
I'm not always around, but could contribute when I can
Aaron Judd
@aaronjudd
Dec 30 2014 21:32
that’s great, always looking for contributors and I’m always available here to help answer questions. whether it’s ready for you to use, really depends on your requirements and how much you’re willing to fill in the missing parts yourself (and hopefully contribute back)
our goal is a “general” platform that hits 80% of the requirements for a typical, but complex shop
so it’s quite possible that it might be ready for your needs much earlier
I know a few shops are using it now, it’s just up to you how much you want to have “out of the box"
Michael Jenny
@prinzdezibel
Dec 30 2014 21:54
@aaronjudd Do you have a URL at hand of a production shop installation?
Aaron Judd
@aaronjudd
Dec 30 2014 21:56
@prinzdezibel nope, we don’t run any (as the reactioncommerce sites are just testing shops), so I haven’t kept track - just a few people have mentioned them me. We should probably start some sort of list that people can add to though
I’d be just as curious as you ;-)
I’d figure at this point it would only be reasonable if they had some alternate backend/order processing. There are a few of those kinds of systems I thought about integrating too, but I’d like to see reaction be able to be fully independant of other systems when we hit beta
we’re actually thinking about shutting down the “alpha preview” shops soon while we finish beta - as that was mostly about us getting feedback and testing for scaling a launch platform.
Everest Liu
@evliu
Dec 30 2014 23:02
Question (since i’m not a mongo connoisseur): I’m trying to systematically create a new variant. With the Meteor.method createVariant, is there a way for Products.update({"_id": productId},{$addToSet:{"variants": newVariant}}, {validate: false}) to return the new variant._id?
actually, i think i’ll extend the function to accept a newVariant optional that will override the default empty newVariant; that way i won’t need the variant._id
Aaron Judd
@aaronjudd
Dec 30 2014 23:04
I was just going to say that I don’t think it would be an issue for me to change that code a little, like:
Everest Liu
@evliu
Dec 30 2014 23:05
yea, because it’d be quite easy and it would make the method more general instead of just for when a new product is created
let me give it a try, i’ll check with you here after i figure it out, then if you like it, i’ll PR it
Aaron Judd
@aaronjudd
Dec 30 2014 23:05
  createVariant: (productId) ->
    unless Roles.userIsInRole(Meteor.userId(), ['admin'])
      return false
    newVariantId = Random.id()
    newVariant = { "_id": newVariantId, "title": "", "price": "0.00" }
    Products.update({"_id": productId},{$addToSet:{"variants": newVariant}}, {validate: false})
    return newVariantId
Everest Liu
@evliu
Dec 30 2014 23:06
either way it may be good to return the newVariantId as it follows normal design patterns for insert methods
Aaron Judd
@aaronjudd
Dec 30 2014 23:06
I’d have to double check that there’s not anything testing the current return (which would be ‘1’)
Everest Liu
@evliu
Dec 30 2014 23:07
ahh alright
Aaron Judd
@aaronjudd
Dec 30 2014 23:08
this isn’t really a mongo thing either - because I’m giving an id to a array of objects - this could have been a collection and then _id would have been ‘real’, but in this case it’s really not a mongo _id
Everest Liu
@evliu
Dec 30 2014 23:09
yea true, but as long as it’s consistent. i totally missed the original “_id”: Random.id()
Aaron Judd
@aaronjudd
Dec 30 2014 23:09
as a practice, I’ve switched to now explicitly defining the ‘return’ as well, coffeescript automatically returns the last result
so this would be a good update, if you wanted to test it and PR it
Everest Liu
@evliu
Dec 30 2014 23:09
yea that part i remember, but i remember reading in your docs to always explicitly return
i haven’t run your test suite before, i’ll take a look
Aaron Judd
@aaronjudd
Dec 30 2014 23:10
for this very reason ;-) it’s not always obvious
Everest Liu
@evliu
Dec 30 2014 23:10
we’re going to try out MUnit for package unit tests, since the others don’t really support package testing (like tinytest, jasmine, etc)
Aaron Judd
@aaronjudd
Dec 30 2014 23:11
the test suite doesn’t work anymore anyhow -it’s been broken for a while, lol. (working on that soon as velocity settles down a bit). so just make sure to run through the basic - “do you see anything broken” - I think this change should be ok
Everest Liu
@evliu
Dec 30 2014 23:11
haha, alright
one day, hopefully you’ll have the finances to hire a good SDET
Aaron Judd
@aaronjudd
Dec 30 2014 23:12
fingers crossed - that will be happening in February
Everest Liu
@evliu
Dec 30 2014 23:13
sweet
  createVariant: (productId, newVariant) ->
    unless Roles.userIsInRole(Meteor.userId(), ['admin'])
      return false
    newVariantId = Random.id()
    newVariant = if newVariant then newVariant else { "_id": newVariantId, "title": "", "price": "0.00" }
    Products.update({"_id": productId},{$addToSet:{"variants": newVariant}}, {validate: false})
    return newVariantId
Aaron Judd
@aaronjudd
Dec 30 2014 23:15
you might want to return “newVariant” if not using newVariantId
Everest Liu
@evliu
Dec 30 2014 23:15
that’s my makeshift coffeescript ternary operator, haha
Aaron Judd
@aaronjudd
Dec 30 2014 23:15
you can use the traditional||
Everest Liu
@evliu
Dec 30 2014 23:15
oh i forgot to set it; to stay consistent, i’d still want to assign it from newVariantId
Aaron Judd
@aaronjudd
Dec 30 2014 23:16
so newVariant = newVariant || { }
Everest Liu
@evliu
Dec 30 2014 23:16
ahh
trying again:
  createVariant: (productId, newVariant) ->
    unless Roles.userIsInRole(Meteor.userId(), ['admin'])
      return false
    newVariantId = Random.id()
    if newVariant
      newVariant._id = newVariantId
    else
      newVariant = { "_id": newVariantId, "title": "", "price": "0.00" }
    Products.update({"_id": productId},{$addToSet:{"variants": newVariant}}, {validate: false})
    return newVariantId
Aaron Judd
@aaronjudd
Dec 30 2014 23:23
looks good, the only thing I am wondering about if you should add a check for price, title ( I think those are required but not 100% sure)
  createVariant: (productId, newVariant) ->
    unless Roles.userIsInRole(Meteor.userId(), ['admin'])
      return false
    newVariantId = Random.id()
    if newVariant
      check newVariant.price, String
      check newVariant.title, String
      newVariant._id = newVariantId
    else
      newVariant = { "_id": newVariantId, "title": "", "price": "0.00" }
    Products.update({"_id": productId},{$addToSet:{"variants": newVariant}}, {validate: false})
    return newVariantId
maybe not needed though
Everest Liu
@evliu
Dec 30 2014 23:25
oh yea, i can set a flag for validate
Aaron Judd
@aaronjudd
Dec 30 2014 23:26
and honestly, it should be done in the schema
Everest Liu
@evliu
Dec 30 2014 23:26
we can do check(newVariant, ReactionCore.Schemas…..)
Aaron Judd
@aaronjudd
Dec 30 2014 23:26
ah yes
Everest Liu
@evliu
Dec 30 2014 23:27
is there a way to just create an object based on the schema? I tried looking through the SimpleSchema docs but couldn’t find anything
like a constructor
i put this in my code: //required variant fields _id, weight, price, title;, convenience info for me, haha
Aaron Judd
@aaronjudd
Dec 30 2014 23:29
ooh, we just had a little earthquake ;-).
let me find an example
Everest Liu
@evliu
Dec 30 2014 23:29
haha, i like how you have a winky face with the statement that you had an earthquake
Aaron Judd
@aaronjudd
Dec 30 2014 23:30
(would have been a different one if it was a REAL earthquake, lol)
just a 3.9, baah
Everest Liu
@evliu
Dec 30 2014 23:30
lol
when I work with the parse sdk for other projects, you can do var newObject = Parse.Object.extend(className)
then I use a convenience class that automatically greats all the setters and getters for each property
Aaron Judd
@aaronjudd
Dec 30 2014 23:33
ok, I’m a little confused how you’d want use it, but I think you’re looking for

ReactionCore.Schemas.PaypalPackageConfig = new SimpleSchema([
  ReactionCore.Schemas.PackageConfig
  {
    "settings.mode":
      type: Boolean
      defaultValue: false
  }
])
where we’re extending ReactionCore.Schemas.PackageConfig, and adding new items?
Everest Liu
@evliu
Dec 30 2014 23:34
well, that creates a new schema, but like a method that allows me to create an instance of the object based on the schema with getters and setters, sorta like a class
kinda like a java/obj-c class, a model in your MVC
like if i created a dog schema (or a dog class), and did var newDog = new Dog()
Aaron Judd
@aaronjudd
Dec 30 2014 23:35
well, I guess we use collection-hooks that way
Everest Liu
@evliu
Dec 30 2014 23:36
ahh ok, i’ll take a look
Aaron Judd
@aaronjudd
Dec 30 2014 23:36
take a look at the hooks.coffee file
and we do have applyVariantDefaults
there
Everest Liu
@evliu
Dec 30 2014 23:46
i feel like it may be better to have a check(object, schema) call in those hooks, that way validation will always occur
and since in a normal MVC pattern, business logic and validation should happen on the model abstraction
any which way, is this sufficient?
  createVariant: (productId, newVariant) ->
    unless Roles.userIsInRole(Meteor.userId(), ['admin'])
      return false
    newVariantId = Random.id()
    if newVariant
      newVariant._id = newVariantId
      check(newVariant, ReactionCore.Schemas.ProductVariant)
    else
      newVariant = { "_id": newVariantId, "title": "", "price": "0.00" }
    Products.update({"_id": productId},{$addToSet:{"variants": newVariant}}, {validate: false})
    return newVariantId
Everest Liu
@evliu
Dec 30 2014 23:52
the only thing missing from the else version and the hooks defaults is the weight, which is required by the schema
then the qty is required too for the actual product to have the ability to be visible / published
then there’s the case that someone once asked about digital products, which have no weight, but i guess you can just put weight = 0
i just noticed something else; the child variants inherit the weight from the parent variant, but what if they do weigh different, because a child variant has the product PLUS a free gift or something
i guess you would just make that a cloned or new variant; haha