Need help?

[andersekdahl]

I just cloned the repo as I'm very curious about this project. But there seems to be some work to be done to make it easy to use. Currently it seems to have a dependency on a few global variables and there's a quite dirty hack to check if a callback has been called by using Thread.sleep.

Just wondering if there's anything I could do to help to push this forward?

[PeteDuncanson]

Hi @andersekdahl,

Yes the usability is not all that great...well actually it is but its simply not documented! Its on my todo list of this week.

Its mainly uses a global var called SuperChargedReact = {} which we store some variables, settings and callback output in. The main reason for this is to allow for ReactRouter to be used. We need to be able to pass in the url requested and then the router uses a callback which we can't control in order to render out the correct component. What we have to do is get this to render out its results as a string and store them back into a var in the SuperChargedReact object.

We don't know when that callback will finish processing as its async within the JS engine hence the "dirty hack" of putting a timer in to poll when the variable has been populated or not. This is not ideal but is there for a reason.

The obvious way to do this would be to get the JS engine to call back out to the host environment (aka .net) and let it know its finished (ie pass the callback to .net) but this has a few draw backs. We would still need to await the callback firing into .net so some waiting around would be required. Additionally when creating a new context their is a performance penalty if you want to link the host to the JS engine, how bad this is we've not bench tested but on the ClearScript site they say there are some big savings to be made (and curse me for not book marking the forum posts I'm referencing to back this up, again I'll have to return with the links in another post). Hence us trying the Thread.sleep idea.

I don't think the length of the sleep is correct (its massive really) but it should work for most peoples computers for now, again in the docs we'd discus tweaking this value to see what you can get away with. I've got an idea to have a way to train it to find the minimum amount of time it needs to perform the task in one interation and set it to that, that should give the fastest response time it can most of the time. Alternatively we could maybe play around with using await somewhere. But before I did that I would like to see the speed penalty if any of linking the host to the js engine and seeing if we can't get that working. So yes it is a "dirty hack" but one that is in there due to some thought. Its a pragmatic hack ;)

If you want to push this area forward let me know your thoughts/ideas on the above and if you want to have a play around with a possible tweak please do so. For my side of the bargain I'll write up some info on how to get up and running with this code better, I'm well aware we have some gaps!

Thanks for the interest.

Cheers

Pete