Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom build and/or extension library #90

Closed
fabien-d opened this issue Jan 12, 2013 · 2 comments
Closed

Custom build and/or extension library #90

fabien-d opened this issue Jan 12, 2013 · 2 comments

Comments

@fabien-d
Copy link
Owner

There has been a few requests for custom functionality. (e.g. #39, #70, #86). So I'm considering three possible scenarios (open to more).

1. Stick to the Basics

The intention of alertify from the beginning was simply to be able to replace native dialogs with customizable ones. The plan all along was to mimic the behaviour and stop. Currently, it's very close and with a few tweaks and optimization, version 1.0 could be just around the corner.

2. Core Library + Extensions

Still sticking with the basics of what alertify was meant for but adding extension that could be added as dependencies to provide additional and more customized options. This would solve the problem about whether a certain feature is useful and generic enough to fit in the core and allow anyone to write extensions without touching the core. This would give greater flexibility and could be extremely useful for advanced users and allow personalization to the library.

3. Custom Build

This would be very similar to option 2, where the code would be split into stand alone features that could be hand picked and then used to generate a custom build.


I'm leaning heavily towards #2 or #3. This would need to be properly scoped out but would love to get feedback on whether this would be useful...

@heston
Copy link

heston commented Mar 7, 2013

I like proposal 2, but only if it doesn't add too much complexity to the core. In my earlier request (#70), I proposed leaving the API more open, so it would be easy to subclass. Then it's a simple matter of overloading the pieces that should be custom. Alternatively, if Alertify were more modular, new instances could be be composed out of stock and custom components, mixin style (e.g. A renderer, various callbacks, etc.). The latter is not really a custom build, since every distribution would be the same, it's just how the pieces are assembled during object construction.

@fabien-d
Copy link
Owner Author

fabien-d commented Mar 7, 2013

I'm still looking for the ideal build to make it easy for users to use and for developers to extend/customize. I've started modularizing it for 0.4.0. You can check it out at http://fabien-d.github.com/alertify.js/0.4.0rc1 and the source code is the master branch.

Still not perfect, but much more structured and a step in the right direction. I'm hoping by the release of 0.4.0 to have an extendable library but also one that can be added to the site in no time.

psolom pushed a commit to psolom/alertify.js that referenced this issue Aug 23, 2016
psolom pushed a commit to psolom/alertify.js that referenced this issue Aug 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants