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

[Search] Api search using custom ajax call #1736

Closed
Trouche opened this issue Jan 30, 2015 · 15 comments
Closed

[Search] Api search using custom ajax call #1736

Trouche opened this issue Jan 30, 2015 · 15 comments

Comments

@Trouche
Copy link

Trouche commented Jan 30, 2015

Firstly, I have really been enjoying Semantic UI. It saves me a LOT of time during the build. Our application is being built in Ember and Semantic is working great within that environment with little or no modifications.

However, today I finally came up against an Ember-specific problem with Semantic. I would very much like to use the Search module to fetch small amounts of data from the server. I understand that the API is the recommended way of retrieving that data. However, while Ember does use the $.ajax method of retrieving data, it doesn't use the typical jQuery implementation but rather an Ember.$.ajax one. Additionally, all data calls are typically wrapped in an Ember promise to ensure that it is correctly added to the Ember run queue. The Semantic API abstracts the actual ajax call. Short of hacking the API (which I really don't want to do), how can I manually specify how I fetch my data? As we may be searching 9000+ records, pre-caching is out of the question.

Clearly, this is beyond the scope of typical usage, but any assistance you can provide would be greatly appreciated. Providing the search with a third way of getting content (local, API, custom), even if it was more complex for the developer, would make the Search module much more flexible for application developers.

Thanks,
John Pendergrast
RocketRez (www.rocket-rez.com)

@jlukic jlukic added the Question label Feb 1, 2015
@jlukic
Copy link
Member

jlukic commented Feb 4, 2015

So my understanding is that calls to $.ajax in ember are done through Ember.$.ajax? Can you provide a link for documentation on this for me within Ember?

I think i can provide abstractions for this inside $.fn.api that could detect for different libraries and call the appropriate internal method.

jlukic added a commit that referenced this issue Feb 4, 2015
@jlukic
Copy link
Member

jlukic commented Feb 4, 2015

In previous/current versions can retrieve an API promise using

var promise = $('.ui.search').api('get request');

I've also just addded in next a new callback onRequest that is called when an XHR request is made, it receives the promise and xhr object as 1st and 2nd params.

$('.ui.search').search({
  apiSettings: {
    onRequest: function(promise, xhr) { 
      // do something fun with this
    }
  }
});

I would also like to add the ability to replace the internal $.ajax call, but need to verify what the best practices are for each backend.

@aaronbhansen maybe you have some thoughts here. Is there anything special that needs to be wrapped with ember $.ajax requests?

@Trouche
Copy link
Author

Trouche commented Feb 4, 2015

I am using a very customized data model with Ember (written by guys close to the Ember team). As such, the only way that I could use the Semantic API would be to be able to manage my own data calls. This, of course, defeats some of the primary purpose of the API. In the interim I have leveraged other pieces of Semantic and created my own lookup (search) implementation. It isn't nearly as pretty or full featured as yours, but it works for now. Thank you for looking into this issue. I look forward to the solution you develop. :)

@aaronbhansen
Copy link
Contributor

Anything referenced under Ember.$ is actually an alias to jQuery as can be seen here. The ajax method would be same same as semantic would be calling on the api. When dealing with plugin callbacks, and all that needs to be done for ember is bind the callback to the Ember run queue.

$("[name=file]").on("change", Em.run.bind(@, @submit))

As far as a generic ember search component, I've taken a look at this a couple times, but I haven't found a good way to make it a generic component. Part of the problem with search (vs the rest of the components), it needs custom callbacks and outside api settings. Most of the other ember semantic modules can pass in everything that the module needs on the init.
While it seems like you can customize some of the api actions directly within the search module, most customized api actions need to be done on the api outside the search module.

To get search partially working before, I had to setup some global settings in the api and some in the search module. Ember works best when each module can be totally customized through the module init. If everything can be passed through to the semantic module in a single call, that would make creating a generic ember search component much easier.

.search({ //all settings (api and search) }}

This might be possible today, I didn't spent a ton of time looking at it yet. Are all api options and callbacks possible through the module init method @jlukic?

In short, there isn't a solution yet. You might be able to create a custom search semantic ember component by mixing in the base class. Any first level settings or callbacks on the semantic module will automatically override and proxy to your ember component through the run queue.

For future module enhancements @jlukic, ember has two main callbacks that deal with plugins, one is didInsertElement and the other willDestroyElement. On didInsertElement, the semantic module is initialized and willDestroyElement destroys the semantic module reference. Anything interaction after didInsertElement, is done through callbacks and settings passed in through the initial module init method. The more callbacks and settings that can be setup directly in the module init, the easier it is to create ember components.

@jlukic
Copy link
Member

jlukic commented Feb 4, 2015

Ember works best when each module can be totally customized through the module init. If everything can be passed through to the semantic module in a single call, that would make creating a generic ember search component much easier.

@aaronbhansen This is possible, any API settings can be passed through search using apiSettings: {} on init.

See this line

@aaronbhansen
Copy link
Contributor

Great, I'll look into going that direction more then.

@Trouche
Copy link
Author

Trouche commented Feb 4, 2015

I would be happy to give more information regarding our implementation if that is useful. Feel free to contact me a [email protected].

@jlukic
Copy link
Member

jlukic commented Apr 14, 2015

@Trouche @aaronbhansen

I've added a few new things to API in 2.0 which should be useful for using API endpoints with custom backends

  • mockResponse - Specify a string or sync function that will return API response
  • mockResponseAsync(settings, callback) - Specify an async function that API that will return callback with API results
  • onResponse(response) - callback which receives server response after API request, and allows the JSON/HTML to be transformed before callbacks like onSuccess or successTest are fired.

I might consider changing the name from mockResponse before releasing.

The original intent was to allow for specifying mock objects that should always be returned, but it seems to be flexible enough to allow other integrations with API that shouldnt rely on $.ajax. Suggestions are welcome

@aaronbhansen
Copy link
Contributor

It would be nice if the search component was separate from the api portion. That way if you just wanted a search component from existing data you could easily do that, or have the api search module mixed in to create an ajax search component.

If you had the search code separated out with the correct hooks, then had an additional api search module that setup the search module and hooked into the search hooks, you would get the best of both worlds. You could either build your own search module from existing data / with your own ajax calls, or you could use the semantic api search module.

Seems like that would provide a better level of separation. Anyway just a thought.

@jlukic
Copy link
Member

jlukic commented Apr 14, 2015

@aaronbhansen You're describing how it works. You can specify a searchable object using source and skip API altogether, check out the local example

@aaronbhansen
Copy link
Contributor

@jlukic yep you're right, I was reading you added mockResponse to search instead of api. I just read your previous update wrong.

@jlukic jlukic closed this as completed Jul 15, 2015
@CarbonMan
Copy link

I have a similar problem in dealing with a legacy app. It seems that if source could also be specified as an async custom function, that would be ideal.

@luiz-brandao
Copy link

Thank you! I have just started using Semantic-UI and it's been very pleasant. I believe mockResponseAsync should be renamed, or have an alias. If one is not doing tests, the name doesn't make much sense. I wouldn't call it a mock if I'm implementing a custom backend. So maybe something like responseCallback would be much clearer. My 2c!

@jdhiro
Copy link

jdhiro commented Dec 14, 2015

We have a library that already provides us with search/autocomplete responses in a Promise, and I was hoping to just wire that into the Search component but it seems very difficult to accomplish. I tried to use a source:function() to return the data, but it didn't like that. I also tried to figure out a way to pick up the input to run my own query that I could them assign to source and run a local search against -- but I can't figure out a way to hook up to the events that would be needed for this. =\

@jlukic
Copy link
Member

jlukic commented Dec 14, 2015

@jdhiro It should be relatively painless using mockResponseAsync inside apiSettings check out API docs

http://semantic-ui.com/introduction/new.html#custom-backends

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

No branches or pull requests

6 participants