Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
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!
Corey Birnbaum
@vonWolfehaus
Speaking of which, my old project uses services, and while they're supported in v1, will they eventually be deprecated in favor of helpers?
Tom Murphy
@bluemalkin
Hi - I cannot get sails postgres to honour the SSL environment setting for connecting to the DB. Anyone else have issues with it ?
here's the issue: pantsel/konga#139
Raj Soni
@soniraj
@edencorbin @martskins Hi guys we have just started sailsit and we are trying to expand. Regarding the website layout, we will be launching our new website layout by today so stay tuned. We have a fb group and twitter page, do follow us.
ChrisWorks
@ChrisWorks
@soniraj This sounds great. Cant wait to have a look.
ChrisWorks
@ChrisWorks
@soniraj Would you be able to structure the content by theme on the site? E.g. "Getting started with Sails", "How to structure your app", "Working with policies". As I mentioned yesterday we need a place to document best-practices and how to work with the various sails features. This would include allowing people discuss how to do a certain thing and then graduate the approach into documented pattern.
Raj Soni
@soniraj
@ChrisWorks do you mean to say, organize content category wise for better readability ?
Alexander Ostapenko
@NachtRitter
about changes to framework I like scheme in Ember where changes are discussed via public RFC https://github.com/emberjs/rfcs
ChrisWorks
@ChrisWorks
@soniraj Yes, one thing we were discussing here yesterday was to create a lexicon for sails "how-to's". Instead of a long list of blog-posts, we would need categorize the content so users can easily find what they are looking for. (not just search for it).
"Getting started guides" -> ... "Sails and email ->" ... "Sails and databases" ... "App architecture ->" .. "Integrations with.... " ... so a topic based navigation. :)
Alexander Ostapenko
@NachtRitter
@mikermcneil does sails-mysql datastore configuration accept parameters for node-mysql driver? I'd like to know how datastore works with pool of connections to MySQL.
Tom Murphy
@bluemalkin
any luck with my query ? :)