Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
ChrisWorks
@ChrisWorks
@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 ? :)
Albert Peiró
@albertpeiro

@mikermcneil the query:

{"where":{"or":[{"name":{"contains":"su"}}]}}

used to be case insensitive in 0.12 by default at least with disk and mongo adapters. I'm upgrading to 1.0 and need to keep it that way. How? Any reference? anyone?
In 1.0 it seems to be case sensitive now..
https://github.com/adminxhq/sails-hook-adminx/blob/sails-1.0/api/controllers/AdminXController.js#L49

Raj Soni
@soniraj
@ChrisWorks nice idea ! once our new layout is up, we can start work on the categorization
Eden Corbin
@edencorbin
@soniraj, another categorization request would be in the forums section. "new to sails", "errors and troubleshooting", "user tutorials", "extending sails", "sails db adapters", "looking for help", just random off the top of head ideas, it's nice that new users have a place they don't feel intimidated posting "new to sails", and that advanced users can better specify their forum topic, and lastly that some categories are clearly not intended for q & a (although the q & a format is fine to leave as it can be used as a comment system at that point) "user tutorials".
Eden Corbin
@edencorbin
If you have async controller routes, any way to have sails auto try catch them all, so you don't have to write a try catch inside each one?
martskins
@martskins
@edencorbin maybe create a function wrapper that returns a controller method and wraps the actual method in a try/catch?
function basicHandler(fn) {
    return function (req, res, next) {
      try {
            fn(req, res, next);
        } catch (err) {
            console.log(err);
            res.serverError(err);
        }
     }
}

// SomeController.js
module.exports = {
    someControllerMethod: basicHandler(function (req, res, next) {
       // Do un-"try/catched" stuff
     })
}