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

[Feature Request]: Backport "Add setSelectionRange to PromptInput" to Textarea component #3297

Open
2 tasks done
purplepenguin2 opened this issue Feb 17, 2025 · 3 comments
Open
2 tasks done
Labels
enhancement New feature or request response-requested

Comments

@purplepenguin2
Copy link

Description

There was a recent commit that exposed the setSelectionRange to PromptInput, but it'd be extremely useful to expose it on the Textarea component as well.

I'd also request exposing the selectionStart and selectionEnd values as well, since without them, the set method itself isn't super useful.

Code of Conduct

@purplepenguin2 purplepenguin2 added the enhancement New feature or request label Feb 17, 2025
@gethinwebster
Copy link
Member

Could you let us know more about your use-case for this? Previous use-cases we've seen haven't needed the selectionStart/End values, so I'm interested to better understand what exactly you're trying to achieve, to make sure this is the best approach.

@purplepenguin2
Copy link
Author

purplepenguin2 commented Feb 21, 2025

Without being able to read the current values, it makes it impossible to keep a persistent cursor after modifying values. For an example, I'm using the Textarea component as a very simple/minimal code editor, so Tab needs to insert 2 spaces, not move the focus to another element. In order to achieve that, I need to update the component's value, then take the current cursor position and add 2 to it, etc.

There's limited value in only being able to blindly set a new selection range while not being able to access to current selection at all. Currently I need to wrap the Textarea component in a div so I can get a ref to the actual DOM element, which is not ideal. If Cloudscape offered some type of escape hatch to at least access the bare DOM element, you wouldn't need to support selectionStart and selectionEnd specifically, but right now, it's impossible to pass a ref or access the DOM element itself, so it makes use cases like tab to insert a space very difficult and require extra boilerplate/wrapper code.

@gethinwebster
Copy link
Member

If you're building a code editor I think you would be better starting with native components and styling them using design tokens, as this is quite a bit beyond the expected use-cases of the textarea component. Recreating the styling should be relatively straightforward as the component itself is not too complex (https://github.com/cloudscape-design/components/blob/main/src/textarea/index.tsx), and this would then give you complete control.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request response-requested
Projects
None yet
Development

No branches or pull requests

2 participants