Search the Community

I've learned this one from Effective Javascript . Basically it says that instead passing a long list of arguments to function just pass an options (opts) object. This way even if you'll add additional args in the future everything will be kept neat and clean and the user (you or others) won't have to guess what each arg is intended for. This may seem like an overkill for simple functions but imagine functions that take 5, 10 or even more arguments. You could say that it is bad practice but you'll have a function like this in your program one time or another. Or you could use named arguments but they do have to be in a specific order (last in args list). And using the opts object has it's advantages - you can pass args in whatever order you like and omit as many as you like and the function will still probably work - because you'll have implemented an arg check section that sets them to defaults - you'll probably do it anyway with normal arguments. So hands down this is the trick that is making my code waaayyy more usable, clean and easy to use. Let's see it in action - I'll be using examples from the book: Here's a function without an option object with lots of args (USAGE): var alert = new Alert(100, 75, 300, 200, "Error", message, "blue", "white", "black", "error", true); Here's the same function with an option object (USAGE) - note that you can input them in any order you want or miss them completely: var alert = new Alert({ x: 100, y: 75, width: 300, height: 200, title: "Error", message: message, titleColor: "blue", bgColor: "white", textColor: "black", icon: "error", modal: true }); And here's the implementation of the function with the option object: function Alert(parent, message, opts) { opts = opts || {}; // default to an empty options object this.width = opts.width === undefined ? 320 : opts.width; this.height = opts.height === undefined ? 240 : opts.height; this.x = opts.x === undefined ? (parent.width / 2) - (this.width / 2) : opts.x; this.y = opts.y === undefined ? (parent.height / 2) - (this.height / 2) : opts.y; this.title = opts.title || "Alert"; this.titleColor = opts.titleColor || "gray"; this.bgColor = opts.bgColor || "white"; this.textColor = opts.textColor || "black"; this.icon = opts.icon || "info"; this.modal = !!opts.modal; this.message = message; } It may be a little bit more work to do for the arg check but you're going to use it a lot more times than write it. And it forces you to do arg check and provide defaults (which is a very,very good thing). And it's more readable and "writeable" IMO.

Hello, I haven't yet seen a post such as what I'm currently writing, but I thought it wise to post how this forum is beginning to bring users together on real world projects. I recently took on a project which as briefly described to me seemed simple enough. Although it was a very short schedule to deliver. One week prior, a key developer @Pryme8 who is often seen on this forum offered to show me how I might optimize code I had posted previously, and I thought to reach out to him directly. Within the first week, I learned that the scope of the project was far in advance of the initial description. Thus, I instictively knew that I would not be able to deliver the project on time, and also lacked some of the fundamental experience required to complete the project on schedule. So I reached out to @Pryme8, and asked if he had time to assist. He was on another project at the time, but was free for one week before my delivery to assist with my project. I'm happy to say that the delivery is now happening this week, and not only was he able to assist, but I learned much from working directly with him. Not to mention, his code is as close to perfection as I've ever seen - but that's perhaps for another post. So what I hope to come from this post, is that we are always stronger working together, as is the world of open source, and if you ever have the opportunity to work with @Pryme8 (I'll with hold his real name for now)I highly recommend you jump at the chance. I could not have delivered my project without this forum, the help from all users, and speificaly the vast experience from the one user I was lucky enough to have contacted me prior. This forum rocks! DB

Hi! We are working on a small game, and we are trying to do so while maintaining a clean architecture, and clean code. We are also keeping up a high test coverage. We don't want to completely rely on PIXI, we want it as a module to use it as a renderer, and we are trying to make it interchangeable any time. So we maintain our own state tree with positions, velocities etc, because storing these are really the responsibilities of the business logic. If PIXI had just a render method, like canvas has, it would be easy to just render everything in every frame based on our own state-tree. But this is not the case, because PIXI forces us to store all the data (rotation, alpha, positions, anchors etc...) inside PIXI stages/sprites/containers, which totally messes up the principles of just using it as a 'view', and not a controller with responsibilities. The question is: how can we cleanly separate PIXI, and really only use it as a renderer. I hope you can help us, because there are no other libraries with this much cool features. Thank you for your time, I'm waiting for your answers.