This topic was automatically generated from Slack. You can find the original thread here.
SERW2039 : re: btw we shipped a fix to support pagination for useQuery: true async options now. So the options function should be called multiple times (as it would be when you’re not using useQuery: true ) - once each time the user reaches the end of the previous page of results (from chat with dylan/tod)
i think there’s an issue on the filter implementation applied to the options display, as i noted elsewhere, the async options method is invoked when the user clicks --load more-- but when the user enters a filter value, the --load more-- option is hidden and no longer there seems to be a way to invoke async options for pulling more options.
SERW2039 : and a consequence is that ever new query entered by the user never gets into the async options. when it comes to reddit, it’s an issue because the default value query“” doesn’t yields results, and even if i enter a filter value I can’t get any more results regardless of the value.
Dylan Sather (Pipedream) : I see, thanks. For the purpose of the Reddit source, I’d go ahead and implement our original plan before we implemented the fix - perform all the pagination within the first invocation of the options method, and return all of the results tied to the user’s query. Does that work?
SERW2039 : I am afraid not, because the first options method invocation is sent with a default empty valued query (it is invoked without actual user’s query), in this instance the result of the search subreddits reddit api is an empty list, no --load more-- or hit options as paginating, and, as pointed in my previous comment, user entered query values don’t trigger options method, which would be desirable.
I tried to implement a workaround by adding an additional prop for “initial query” but it looks like that when performing pd dev, the value entered is not available for the other props downstream the code execution in the reddit.apps.js file
Dylan Sather (Pipedream) : I can confirm this appears to be an issue when running pd dev. For example, the Stack Exchange - New Answers for Questions component works great in the UI (options method runs when I enter a query, and the UI triggers the options method again at the end of a page), but in the CLI, the options method doesn’t appear to get run when the user enters a query. You can validate by running pd dev on components/stack_exchange/sources/new-answers-for-questions/new-answers-for-questions.js .
TJ Koblentz : yea i punted on the improvements in the CLI, but i’ll take a look soon to fix that… it might be more complicated there because of the dependency we use
TJ Koblentz : right this second? im not sure i’d have to play with it or understand the behavior again… was going to try to just fix it but it might be a few hours
SERW2039 : guys @U019EEQLNSG@UR84EMEUT I have a PR ready to review. Essentially I implemented dynamically pulling options to one prop, using a workaround Dylan recommended after an issue faced when using CLI. After testing on the PD UI, I thought it was best to pull all options in one go, and repopulate only when the user modifies the query. Therefore, the “load more” options doesn’t pull more options, as all results are shown to the user on the first refresh for a given query.
Jay Vercellone : The CLI can be tricky in that regard, especially when dealing with text input from the user. For instance, one edge case is the user pressing the space bar while dealing with a string[] prop input. In the CLI, the expected behaviour of the space bar is to mark/check the selected option, while in the UI the space bar would be just another text character.
Jay - I think Sergio’s at the point where it would be good to show off the common technique you’ve used. Sergio - Jay’s developed this really neat technique for abstracting common component code that can’t be included in the app file into a single, common.js file (e.g. the subreddit prop, timer prop, and reddit app prop is in all component, so that can be included once in a single file and required in each component - check out Bitbucket for an example). I think there could be some room to adopt that technique here.
SERW2039 : So I am about to start abstracting out to the common.js file. However, I wanted to touch base in what I see should be included in the common.js and what should stay in the service.app.js file.
SERW2039 : Essentially, the common.js includes code that supports the setup and are common of,to the components, basically technicalities such as prop definitions, or common hooks logic in activate, deactive, where was the service.app.js will contain actual code accessing the service’s api, i.e. the endpoints consumed by the different components.
