Limit FeatureLayer features to the current extent?

[JimNoel]

Is there a way to get FeatureLayer to limit features to the current extent?  I’m trying to use a FeatureLayer to display some features in 3D.  The layer has ~180,000 features.  When displaying features, FeatureLayer doesn’t seem to take the current extent into account, and tries to get everything. 

If I’m zoomed into a small area, this usually means that nothing is displayed, because the server just returns the first 1000 features it finds in the database (maximum # of records returned is 1000), and none of these features happen to be in the current extent!

Is there a parameter I need to set?  Or is this something that will be addressed in a future API version?

[ThomasSolow]

I don't believe this functionality exists yet, though I'm sure it's on the way.

You can query a feature serviced by extent manually, so it would be possible to set this up yourself for the time being.  Here's a sample that queries by extent whenever the extent changes, with a 200 ms debounce: JS Bin - Collaborative JavaScript Debugging 

That sample uses a graphics layer as a proxy for the features.  Every time the feature service is queried, the graphics layer is cleared and the new features are added.

I also could only get that to work in a Scene View.  There's some issue/bug that prevents the renderer from being cloned in a MapView.

[JimNoel]

Thanks for the quick response, Thomas! I'll check out your alternate

solution.

[ThomasSolow]

Okay, looks like the issue with MapView is that that renderers on a graphics layer are not supported on a MapView.  The documentation says GraphicsLayer doesn't support renderers at all (which doesn't appear to be true in 3D).

You can work around this issue by setting the symbol manually on each returned feature:

JS Bin - Collaborative JavaScript Debugging  

[TristanSebens]

Hi Thomas,

Thanks for your reply to this question. Very helpful. Do you have any idea what the ETA is for this feature? I ask because its important for our application that we have it, so if the fix is a long way off, then it makes sense for us to invest time into a workaround. If the fix is expected soon, however, then it makes sense to simply move on to other issues.

[ThomasSolow]

I don't see an ETA in the functionality matrix.  This feature exists in the 3.X API though, so it may make its way to the 4.XX version eventually.  It seems pretty important to me, although there may be other workarounds for this kind of functionality I'm unaware of.