2

Is it worth considering exposing the "state" of a projector?

I can see a use case where being able to externally detect the status of a projector might be able better schedule (or abandon) some activities in larger frameworks.

Currently, internally within the projector, there are the scheduled and renderCompleted items. I could see something simple like isBusy(): boolean as a way to externally signalling that the projector is in the process of doing a render. That way, in any macro framework, transitory state changes, which won't ever be represented in the DOM, could be abandoned.

Of course that invariably leads to the desire to have some sort of notification when the projector becomes "unbusy". Of course, just scheduling the next animation frame for any "onunbusy" work should work without putting any burden on Maquette.

Kitson
  • 1,650
  • 1
  • 18
  • 36

1 Answers1

2

The dilemma here is that we positioned maquette to be a minimalistic library, and the Projector shipped with maquette is already sufficient for every-day use. Macro frameworks could easily implement their own custom projector in only 80 lines of code.

Adding this one isBusy(): boolean feature is only a small addition (both in download size and learning curve), but I doubt it will end there. I would encourage you to experiment with a custom projector. If, in the end, it turns out that the isBusy feature is really the only addition that you needed, send us a pull request and we will be happy to integrate that.

Johan Gorter
  • 1,253
  • 10
  • 13