Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Alexandre Madurell
@amadurell
@TonyZPW @oliverkuehne :)
Oliver Kühne
@oliverkuehne
:)
Jordi Hereu
@jhereu
@ChrisWorks you can use async to acomplish the same result
ChrisWorks
@ChrisWorks
@jhereu Do you have an example? I know I can just have a more complicated afterCreate function, but I find the other way was much nicer. Especially when extending objects. E.g. if you have a Person model it was easy to extend it (e.g. Child) and also add special afterCreate functions only for the Child.
martskins
@martskins
I would avoid calling the afterCreate of Person (in your example) cause it could get messy with the next calls but it should look something like this
// Child.js
afterCreate: async function (values, next) {
    await Person.someCommonMethod(values);  // Assuming all these return promises
    await Child.someOtherMethod(values);
    await finallyDoThisToo(values);
    next();
}
it's kinda messy by itself though, cause of the next callback and async/await mix up
that would be nice to see, promisified lifecycle callbacks
ChrisWorks
@ChrisWorks
@martskins This does not really fix the principle I think. The Child.js should not have to know the functions needed to be called on the Person.js. I think a more generalized approach would be better. Would this be legal:
// Child.js
afterCreate: async function (values, next) {
    await Super.afterCreate(values);  // Assuming all these return promises
    await Child.someOtherMethod(values);
    await finallyDoThisToo(values);
    next();
}
martskins
@martskins
it will probably fail due to the missing next param, but anyway .. even if it does work it's really untidy.. because for that to work Super.afterCreate should return a promise.. and calling next() (inside Super.afterCreate) and returning a Promise after that seems like a mess to me
mixing callbacks and promises is generally a bad idea
what I would do is move the logic in Super.afterCreate to another method.. Super.postCreate or something.. and call postCreate both in Super.afterCreate and Child.afterCreate
martskins
@martskins
it doesn't really solve the mess all the way (promisified lifecycle callbacks would) but it's better in my opinion
ChrisWorks
@ChrisWorks
@martskins Yes, it is perhaps the least messy option, but it is a shame there is not a cleaner way. It is annoying the old way of injecting functions into a lifeCycle array is not supported anymore as this now also creates a lot more work when migrating from 0.12 to v1
Jordi Hereu
@jhereu
@ChrisWorks Sure! Having async, you could use sails lifecycle as a caller to this secuence of functions you had before, as in:
afterCreate: function (values, next) {
         var async = require("async");
         async.waterfall([
                  function myFunctionOne (callback) {
                            // whatever logic
                            return callback(err, data1);        
                  },
                  function myFunctionTwo(data1, callback) {
                           // whatever logic
                           // arg data1 is the returned arg from myFunctionOne
                           return callback(err, data2);
                  },
         ...
        ], function onDone(err, data) {
                  // finished
                  // err is whichever error you returned. Once a function from the waterfall fails, process is stopped and onDone is called
                  // data is the returned data from the last function of the waterfall
                  return next();
         });
}
for more intel about async, here you have the docs http://caolan.github.io/async/
ChrisWorks
@ChrisWorks
@jhereu Thanks, but I was looking for if you meant that async could do the same as defining the afterCreate as an array of functions. And your async approach cannot do that. As per discussion with @martskins this is not a callback vs async issue but how the old "way" allowed me NOT to worry about what other functions needing called.
@jhereu @martskins I dont really know why the array declarations for lifeCycle functions was removed. It could have been implemented to allow async functions to be added instead of callbacks if that was the issue.
@mikermcneil Why was the array declaration of lifeCycle functions removed?
Jordi Hereu
@jhereu
@ChrisWorks Oh, then I would do a custom global function to pass the array of functions you used before as arguments and call them synchronously as I said before with the async method, to change your current code the less as possible

something like...

function execute (funcs) {
   async.waterfall(funcs, function onDone() {
      return cb();
   );
}

and model:

{
   ...
   afterCreate: exec([func1, func2, func3...])   
}
Daniel Elidio Mendes Jr.
@danielelidio
Hi everyone
I have a question over here regarding v1.x
is this version supposed to accept create nested associated objects in a single request? I mean, let suppose that we have a model 'person' which has many 'addresses'
if I send a post like:
{
"first_name": '...', "last_name": '...',
"addresses": [{addressLine1: "...", "city": "..."}]
}
I got an error telling me that sails was waiting to receive an array of primary keys for addresses...
Mike McNeil
@mikermcneil

@chrisworks the team’s philosophy with v1 any time we discovered a bug, or major inconsistency, or recommendation we found confusing was “Why should we keep this in core?”

Sails is huge, spanning many repos. It’s super easy for us to forget something exists if we never use it ourselves on the core team. So if we run across something that encourages patterns we no longer advocate, it’s tricky. We want backward compatibility as much as possible, but the code that implements said backwards compatibility is heavy and it dramatically slows down how long it takes us to add new features— or worse, we add them but with bugs. (I can’t imagine how long it would have taken to add soft deletes and at-rest encryption this Fall if we hadn’t cleaned things up first)

And also at the same time, it’s not just about compatibility— it’s about convention over configuration for consistency between projects, having better error messages for bad usage or mismatched config, and ensuring that the framework you’re placing your trust in has as few “unconsidered edge cases” as possible.

For example, who knows whether we did an isArray check for lifecycle callbacks before? If we had done if (_.isFunction(lc)) { /*...*/ } else { /* ...handle array of functions */ } then who knows what would happen if you passed in a dictionary like {}? Or like... NaN? Worst of all, you might not see an error at all, and then later on get really confused by several little things like that stacked on top of each other. And that’s a terrible experience for any developer to have to go through! Plus it chews up engineering hours— a perfect example of “technical debt”.

So in Sails v1, we’re laying down the law. Anytime there was an opportunity to simplify something like that and eliminate some bloat, we weighed the compatibility cost and in many cases, made breaking change.

If something was an experimental feature we didn’t advocate using, or that was never documented because it was too hacky, it was out. Any feature that was originally a from a “guilt merge” PR instead of based on its merits: that was out too. And, most numerous of all, things that were originally my “brilliant” idea, and that I advocated for fervently, but was flat out wrong about 😫 (eg the whole custom adapter methods thing 😣). We axed those too

I realize it’s kinda annoying right now as you upgrade your app to v1. Sorry about that. Please just keep in mind that, when you’re finished, there’ll be a much better chance that the features you’re using in Sails are things that its author and maintainers understand and use almost every day. And you won’t have to do it anything like it again for a long while— not until sails 2.0 becomes a thing– and even then, it’ll probably never be to this extent again. (Like Node core, our contribution guidelines and processes have matured a lot over the last 5 years)

Alexandre Madurell
@amadurell
Sargo Darya
@SargoDarya
And here I am being glad that this is just being maintained xD
Alexandre Madurell
@amadurell
@SargoDarya is right, @mikermcneil Next time either of you is around Milan, I'll gladly invite you to italian icecream. :)
Jonathan Leek
@mrjonleek
Hey all, using Sails 1 finally (it’s great!) - I’m used to relying on the beforeValidate method to normalize some data before “insert” but I can’t seem to access that hook in 1. Is there an alternative approach?
ChrisWorks
@ChrisWorks
@mikermcneil I get what you are saying and your points are valid, and though backwards compatibility would be ideal I understand that with the resources available it will not be possible. I do think it would be beneficial for the sails community if there were more information on best-practices when trying to re-implement / migrate some 0.12 code to v1. For instance with the array declarations of the lifeCycle callbacks in v.12, what are the options in v1? and what is the preferred pattern from the experts? :smile: I wish we had a community place (or do we?) to contribute / discuss design patterns and best practices for Sails apps. The official doc is great for syntax but does not go deep enough into app architecture and examples are pretty basic. Issues in the repo are for something else. Stackoverflow is flooded with old information and people trying to quick-fix your issue. Am I alone in this? :worried:
martskins
@martskins
@ChrisWork that would be awesome
ChrisWorks
@ChrisWorks
@martskins I think so too. It should be a place of structure (some at least) but where everyone can contribute and comment. We should be able to categorize / tag, mark things as current, old, unproven, needs updating to latest version, whatever. I would like to find patterns on authentication, single sign-on, database related stuff, model structure and optimization, pub-sub patterns and more. Much of it can be links-wrappers to some of the great articles already written, but could be commented on and perhaps marked as "working for v1", "needs rework for latest version", etc. Right now I spend way too much time googling for how to do this and that. This could also include a list of sails modules that are still supported, what version they support and what alternatives exists, etc.
ChrisWorks
@ChrisWorks
@martskins @mikermcneil I like this channel, but things gets lost here and you are at the mercy of whoever is awake at the time of your question and follow up debate is almost impossible. Do you have any ideas on how we could achieve something like that? We would need both the sails community and the core sails team support and "stamp of approval"
Eden Corbin
@edencorbin
Somebody posted here a few weeks back about a sails community site, not sure how big/used it is, it had a few howto articles.
martskins
@martskins
I believe it was a facebook group/page
http://sailsit.com <-- that one
Eden Corbin
@edencorbin
is that a facebook page? I would have guessed wordpress, but I'm not familiar with facebook page customization. I don't much like that you have to scroll through post style entries, a contents/directory, or better way to search articles would be critical.
martskins
@martskins
my bad, my wording was not the best, its a website, but it does have a facebook page
I actually follow the page on facebook
to be honest though I believe it would be nice as an addition to the official docs.. a blog is not really practical to search for docs.. although it's a pretty big "feature request" and not necessarily something the sails team are/would be interested in
Eden Corbin
@edencorbin
Agreed, I'll shoot the sailsit facebook page a message, maybe they could make some updates, or consider joining up with other sails users to overhaul it. Theirs a post from yesterday, it looks actively maintained.
Eden Corbin
@edencorbin
Is there no official forum? That could be nice/simple to add too.
martskins
@martskins
I don't think there is.. or at least no other than stackoverflow (as with most things in life)
Eden Corbin
@edencorbin
Good point, maybe stackoverflow supersedes forums for a framework like sails.
Problem is stackoverflow requires a question/answer format to my knowledge, imagine the downvotes for posting a sails tutorial, vs a forum could have a section for it...
martskins
@martskins
too bad stackoverflow documentation was shut down, that would have been a nice place to do this
martskins
@martskins
speaking of documentation... do you guys use documentation generators? as in JSDoc or docco or anything? any preference for any of them?
I have yet to find a good doc generator that has good documentation :disappointed:
martskins
@martskins
damn.. why didn't I find about docco earlier..
Corey Birnbaum
@vonWolfehaus
@mikermcneil I totally support the v1 changes, my code looks and works better with them :thumbsup: I created a new project that started with v1 so I got used to it that way, but tonight I'm going back and upgrading an older, very large project... gonna take a while, but I know it'll be worth it :) Keep it up, and thanks a ton for staying with this thing!