> Great job @jinyang628! The overall logic is solid. We may want to include the loading UI inside 'wadl' route only, as it's a local state. User can still go to other tabs while wadl is being loaded. Another reason is that, we don't want to interfere with application level layout, if there is an error in setting the loadingWadl state, the whole application is stuck at loading UI as we lost "{{outl
> We are very close! It's not necessary to have wadlstate service. The state can be tracked in webql service. Actually it works better when webql tracks the state, as it is responsible for fetching wadl. The state can be set and reset within the fetchWebqlResponse method. It's fine to leave a tiny gap between data is loaded and data is rendered. The key is to ensure the data state is reliably mana
wadl-inspector/#35 Manually coded query field logic
· app/components/query-field.hbs[view]
Rectified
wadl-inspector/#35 Manually coded query field logic
· app/templates/application.hbs[view]
Rectified
wadl-inspector/#101 Implement call to validation API
· app/services/webql.js[view]
I separated the validateSyntax and prettifySyntax call into 2 separate functions (even though it is the same endpoint) for 2 reasons
1. I can do the isPrettifying check within webql.js and not within application.js. Since validateSyntax is being called every time a user types something into the query field, i cannot do the check within this function.
2. The API endpoint for validation and pret
wadl-inspector/#101 Implement call to validation API
[view]
app/services/webql.js[view]