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

Usage in a browser #1

Closed
rogierschouten opened this issue Feb 6, 2015 · 8 comments
Closed

Usage in a browser #1

rogierschouten opened this issue Feb 6, 2015 · 8 comments

Comments

@rogierschouten
Copy link

Great idea, tsreflect! We were just about to invent the wheel ourselves.
I'd like to use tsreflect in a browser with browserify. For that scenario, I'd have to be able to load JSON data from strings instead of from files/modules. Something to add maybe?

@meirgottlieb
Copy link

Could you tell me a bit more about how you plan on using it so I can think about how loading from a string would fit in?

@rogierschouten
Copy link
Author

The use case is simply examining the JSON in a handy way to make a run-time type check for data sent from server to client. In other words, there is no instantiation and no loading of modules should be required.

That said, loading of modules is entirely possible if done through require(). Even e.g. 'fs' has its browserified version.

Maybe this is outside the scope of tsreflect or maybe tsreflect could be split into two modules: one for sec JSON symbol inspection and another the more intelligent work (which is likely to differ between use cases anyway)

@meirgottlieb
Copy link

The JSON declaration can include references and require statements. How would you see those being handled if the initial data was loaded directly via a string (or JSON)?

@rogierschouten
Copy link
Author

My use case has a number of simplifications, but I can see how this could be implemented in general.

First, the simple use case: Since the data is communicated through json over http, there are only interfaces, basic types, enums and arrays (and the orthogonal combination of these). Furthermore, I'm assuming that all type names are unique. Given that, I can just read in a bunch of .json files beforehand and find the types I need without complex dereferencing of require statements etc.
In fact, I'm almost done with a function that does exactly that and checks incoming data for type adherance.

However, I still think the general case can be handled if the JSON data included a "path" member for each JSON object. Then you could implement full-blown module loading semantics. Simply hand an array of all JSON 'files' to tsreflect.

@meirgottlieb
Copy link

Are you just using the .d.json files directly?

@rogierschouten
Copy link
Author

Yes I currently am.

@meirgottlieb
Copy link

That’s probably the best thing to do. The tsreflect module is probably a bit heavyweight to use on the client anyways.

@rogierschouten
Copy link
Author

I think you are right, that's why I was on about splitting tsreflect up into two modules. If one could split the search functions from the instantiation then users of tsreflect would become less dependent on the actual JSON format used since they would query the data with functions. This could then also include better require() resolving with path members.

But maybe this is all getting out of scope. It seems we've reached an understanding.
Feel free to close this issue or leave it open to see if we can get more input, I'm fine for now, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants