Why remove the global?

[zhenyasav]

It was great to be able to fire IronRouterProgress.start() and .done() when performing heavy tasks on the client. We built a large app that worked with this very nicely. From a usability perspective, it's great to be able to use the exact same visual motif to represent busy work on the client regardless of whether it's a navigation between routes or a long server call on the same route ... etc. Now that it's meticulously hidden, I will need to fork and brutalize. Why was this great feature removed?

[Multiply]

It's going to be added back, when I seperate the progress-system and the design into two packages, that work together.

Can you show me an example of how you used it?

[zhenyasav]

Let's say I'm on a route viewing a document that can be shared with other users, and a Meteor.call needs to be made to convert a user entered email address to a userId. This call will naturally take some time. I use a doWork utility to wrap work functions with appropriate timeouts to keep the DOM responsive and allow the user to see animations begin. I use prime numbers in the timeouts, as this helps slower/older mobile devices running cordova to avoid timeout collisions (sometimes the browser will simply drop a timeout function if too many are scheduled to execute at the same time or too close to each other on CPU starved machines).

Progress = IronRouterProgress # this used to be possible, now we have a hack for this
Utils.doWork = (work) -> 
    if typeof work is 'function'
        t = Meteor.setTimeout
        t ->
            Progress?.start?()
            t ->
                work? ->
                    t ->
                        Progress?.done?()
                    , if Utils.isMobile() then 263 else 101
            , if Utils.isMobile() then 113 else 29
        , 3

# do some work:
Utils.doWork (done) ->
    Meteor.call 'find-some-stuff', (err, result) ->
        doSomething result
        done()

[Multiply]

This is indeed going to be possible in the next version.

The packages will consist of:
Progress Core - Here you can start, and stop the progress as you desire
Progress UI - This is the standard implementation, and you can just remove this package and use your own, to change the layout
Iron Router Progress - This package, that combines both of the above, while also implementing it directly into the IronRouter flow.

Also thinking of ways to properly implement "Progress UI", where you won't need to remove the package, to override what it does.

[zhenyasav]

Sounds great!

With respect to overridable progress UI, sounds like you have the right idea that there are two core components: a "determinate" display of progress between 0->100 which is implemented as a bar on top, and an "indeterminate" spinning element. I wouldn't invent any more kinds of progress elements, these two are great.

Customizing these is a matter of supplying my own custom DOM and CSS as far as I'm concerned:
I would like to say:
hey IronProgress, take my element here: .my-progress .circle and apply to it (or to an ancestral element like body or html or an element of my choice) some standard class when you're in progress. Let me configure that class name in case I already wrote up some css around it.

Using this I can go bonkers creating fancy animations and multi-element visuals as I please. The core of the progress controller is all about applying a class and removing it when progress starts or stops.

For the determinate case, I want IronProgress to apply a style="<css_key_of_my_choosing>:<value_that_I_can_format>" to an element of my choosing. Perhaps the value formatter function feels like this: (progress) -> value where progress ranges from 0..1 and I'm expected to format it into a value string. Perhaps I want that to be opacity:0..1 or width:0..100% or transform: translate3d(0,0,-30..30px). All is possible with a target selector, a configurable css key and value formatter.

[krlicmuhamed]

Any update on this? Is this project dead?