Roadmap v2

[thiamsantos]

Some things to do on the next major release. The changes can be made on different branch, can be called v2 for convenience. Every suggestion needs to be approved, after that it will be included on the list below and further discussion about it should be made on its own issue.

---

• Develop tool for create smaller of images Add support for creating smaller image version #13
• Add offset option offset option #7
• Improve cross browser compatibility IE10 compatibility  #6
• Write tests (visual, unit and cross-browser) Write tests (visual, unit and cross-browser) #16
• Integrations Integrations #17
• Git Hooks Git Hooks #18
• Migration guide Migration guide for v2 #19

[thiamsantos]

Some other suggestions waiting for approval:

• Write tests
• Simplify API
• Integrate with Travis CI
• Integrate with Coveralls
• Add cross-browser support test using Sauce Labs
• Add Git Hooks to prevent bad commits

[thinker3197]

Roadmap -

0. Write tests - Yes, this is a must and we'll do that. Include visual and cross-browser tests both.
1. Simplify API - Not sure if I really understand what you mean here. Maybe we can have more discussion on this.
2. Integrations - Use travis first. Once tests are written to a cover suitable portion of the api, add coveralls too!
3. Git hooks - Can do that. Give the least priority to this at the moment.
4. Add migration guide - The 2nd version will use SVG's for image rendering, so we're going to introduce a breaking change to the api. We need to add a basic migration guide for people using v1.0.x to shift to v2.0.0.

[thiamsantos]

I create a issue for each feature to be added. #16 #17 #18 #19

With simplify API, I was trying to say that the methods provided by the project should be more simple. Instead of proving two methods .init() and .render() could be exposed as just one function progressively().

[thinker3197]

.init() and .render() methods both have different & defined jobs to do. The init() method is for initialisation of the initial variables, setting up event listeners. It doesn't contain any library logic. The render method is a private method to library (although I've exposed it in the public api to let people fiddle with it if they want) which adds library logic to the elements.

As for the issues, good job @thiamsantos. Priority one is to add offset option to current version and release a patch for v1.x.x which I'll complete today or tomorrow. Then we can start working on v2.0.0.

[thiamsantos]

Could you show me a use case for the .render() method? I just pointing that because I can't any use case for it outside the scroll event listener since it only render the images if the image is "on the view".

[thinker3197]

Consider a case where you want to toggle the loading of some image based on another image. To handle such situations, one might want to alter the render() method and pop/push the image based on whether the other image is loaded.
Ps: It might not be the best example, but we can get a situation like that and hence having such methods (i.e. the methods which do not contain the rendering logic) can be exposed for developer.