I am writing a JavaScript plugin for fun. The plugin allows the user to pass options to initialize the plugin and perform actions. It is a simple alert/confirm plugin just for fun.

I am hoping to receive some architecture help with a little bit of code I am working on. It works as is, but I feel like there is a better or more efficient way of doing what I am doing below. ​ The ideal syntax that the user would use (when utilizing the plugin) would go something like this:

new Bulletin('success', 'a title', 'a description', { duration: 2000 }).notify();

​ Or:

new Bulletin('warning', 'a title', 'a description', { duration: 2000 }).ask();

​ The plugin has 2 parts:

  1. Get a few base parameters (color, title, description) as well as some optional parameters (duration, size, class, etc.)
  2. Pass what type of notification is being initialized: notify (alert) or ask (confirm)

The current plugin implementation is this:

import Notify from './notify';
import Ask from './ask';

var default = {};

var Bulletin = function(color, message, title, options) {
  this.settings = Object.assign(defaults, options);
  this.color = color;
  this.message = message;
  this.title = title;

  return this;

Bulletin.prototype.notify = function() {
    Notify(this.color, this.message, this.title, this.settings); 

Bulletin.prototype.ask = function() {
    Ask(this.color, this.message, this.title, this.settings); 


As you can see, the code works. I am wondering if there is a better, more efficient way of achieving this though.

Put simple, is there a way to do something like this (maybe ES6 has something?):

  • Use the constructor's properties without just referencing them with this
  • Depending on which method is called from the constructor (i.e. .notify()), perform different logic
    • The user of the plugin will be able to call either a notify or ask method which will either show an alert or confirm (ask for user input) box - think native JavaScript alert() and confirm(). Therefore, the code that performs those actions would be different. One would simply show a div and the other would show a div but with buttons for the user to select yes or no. But at the end of the day, they would share a lot of the same options. So what I am trying to avoid is duplicating code that is shared between the notify and ask methods, if possible.

The code for these features (notify & ask) is not written yet. I maybe should've waited before asking for a review, but really what I am after, and what will possible drive the rest of the development, is how to create a public JavaScript API that shares parts of "setup" code (gathering params, merging objects, etc.) but then has separate logic depending on which method is called.

Another option is to make the usage something like Bulletin.notify(params), but then I would want to be able to perform things like extend on the options, without writing that code twice for the 2 different types (notify and ask).

My inspiration (if you haven't guessed by now) is notie.js if that gives you an idea of where I'm headed. That may provide a clearer picture of what this code will do eventually.

  • \$\begingroup\$ One little thing: "Color" shouldn't be anything but a color, either in hex or name. 'success' is not a color; neither is 'failure'. Also, you don't show us .ask(), which you used in the example code. \$\endgroup\$ – Nic Hartley Nov 17 '15 at 20:00
  • \$\begingroup\$ Thanks for your feedback! I changed all prompt() references to ask() and the color variable is just poorly named. I think at this point what I want for that variable is it to be more of a style name. Similar to Bootstrap's modify class for many of its components (info, danger, success, etc.). \$\endgroup\$ – james Nov 17 '15 at 20:42
  • 1
    \$\begingroup\$ Good job fixing it :D One more note though: You should probably include the other files as well, since there's honestly not much code to review here. At the very least, if you really don't want them reviewed, link them, so we can see what's going on in them and how it works. \$\endgroup\$ – Nic Hartley Nov 17 '15 at 21:01
  • \$\begingroup\$ Depending on which method is called from the constructor (i.e. .notify()), perform different logic - I'm not sure what you mean here. What prevents you from doing different logic on the methods? What does "different logic" mean anyways? \$\endgroup\$ – Joseph Nov 17 '15 at 21:02
  • 1
    \$\begingroup\$ You might be interested in the way Crockford recommends creating objects. In your case, are you sure "notifications" and "asks" are part of the same "bulletin" concept -- or does bulletin merely exist as a fake superclass because you want to share some code? Eg, "asks" need to potentially validate, process, and respond to user input, "notifications" don't. Rather than join them under "Bulletin", maybe both could use a "BulletinSettings" object that contains the common code? \$\endgroup\$ – Jonah Nov 18 '15 at 1:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.