[v6/v5]: Is it possible to support shadow the use of the Bootstrap Javascript plugins within the context of the shadow DOM?
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- javascript
- Área
- frontend
Línea de trabajo
Empieza reproduciendo el experimento enlazado: clona el repositorio, cambia a shadowdom-experiment, ejecuta npm install y ejecuta npm run start:dev. Inspecciona el comportamiento de Bootstrap Collapse y el problema de ámbito del documento del modal descrito en #36918. Para darlo por terminado, sería necesario acordar el alcance de la compatibilidad con Shadow DOM en todos los plugins de JavaScript y las pruebas de aceptación correspondientes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Prerequisites
- I have searched for duplicate or closed feature requests
- I have read the contributing guidelines
Proposal
OK I've had a look at the issue register and there have been requests to add shadow DOM support in different capacities, ways, shapes and forms if you would like to call it, for example:
- https://github.com/twbs/bootstrap/issues/14200
- https://github.com/twbs/bootstrap/issues/24918
- https://github.com/twbs/bootstrap/issues/28131
Yes all of them have been closed but with each of those examples above, they have been closed at least 2 years ago and now with support for various technologies such as web components and shadow DOM improving and considering not even sure if v6 is in an early enough stage of development (or if some little tweaks are possible in the context of version 5), I would like to request a feature that allows us to at least have the Javascript plugins supported in the shadow DOM from the onset.
This can be either writing web components that support shadow DOM, or using what Bootstrap has been using, but with shadow DOM in mind or even something we can pass in the config to allow us to change the context of DOM selection to allow us to use the shadowRoot selectors.
Motivation and context will be provided below to give a better understanding, which hopefully forms part of the justification.
Motivation and context
Currently I'm on a project that is using a different UI framework for an app. As part of a UI rebuild we are doing for that app, we are looking to progressively migrating our old UI components/elements to use a new framework that is based heavily on bootstrap as a dependency.
In order for our components to co-exist with the old framework while the migration is going on, we had to resort to using shadow DOM to fence off areas using the old UI vs areas using the new UI.
We sort of are in our initial stages, in this process and just trying out a few things to see how far we can go and see what problems we can encounter.
So far the CSS side has now been resolved and we can use Bootstrap's CSS with the shadow DOM and the REM font sizes will not get affected by the root element using the old framework.
On the Javascript side however, it doesn't seem as straight forward to use the current v5 bootstrap JS plugins.
It seems like many of them still seem to rely on us to add additional event handling ourselves (which may end up not being like for like), and since most of the DOM selection seem to be based on the document scope. Furthermore because of the document scope, some of that code would be kinda dead in the shadow DOM, called to do essentially nothing.
I have a branch of a repo that I used to create the simple initialisation of the Collapse, using javascript to instantiate the collapse instance. (Clone https://github.com/classicmike/stencil-bs-collapse-modules-bug.git and checkout shadowdom-experiment, run npm install then npm run start:dev.
As you can see, none of the simple things such as clicking to toggle collapse works and even the DOM selection methods such as the triggers return empty arrays. Hopefully I haven't caused any bugs.
Then there's also issues like this where the modal hard codes, where the modal seems to have been hard-coded to use the document scope which makes launching modals without any CSS issues impossible. This link should be enough to demonstrate issue: https://github.com/twbs/bootstrap/issues/36918.
Furthermore, there are hints where methods or referenced issues and have been use to support a shadowRoot on a case-by-case basis such as:
findShadowRoot()method for https://github.com/twbs/bootstrap/issues/24918
So there seems to be some precedent already for Shadow DOM's usage.
Now it's been around 5 years since the last reply on issues related to supporting web components: https://github.com/twbs/bootstrap/issues/28131 and even then feedback seems quite strong and the support for using it is getting better, it might be a good time to re explore this issue and anything related.
Even if the use of web components may be perceived as a 'step too far' here for v6 or v5 for that matter, I would like to see at the minimum, consideration for the shadow DOM context in the javascript plugins so we can use them in use cases like I have explained above.
Hopefully this request is a reasonable one and would be interested to hear what the position would be going forward.
Thanks.
- Lenguaje dominante
- MDX
- Estrellas
- 175k
- Forks
- 78.7k
- Merge medio
- 1 d 5 h
- PR fusionados (30 d)
- 109
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de twbs/bootstrap
-
v6 alpha - hover-lift effect on menu dropdown only works when mouse is over the buttonPosiblemente ocupada @Aryan9891 la tomó hace 3 días. Abiertobug confirmed css has-pr v6
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
Dialog closes when a file input inside it has its picker cancelledPosiblemente ocupada @samyferhat la tomó hace 3 días. Abiertobug confirmed has-pr js v6
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
twbs/bootstrap#43278 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
docs js on-hold v6
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Toasts seem to be hidden behind drawersPosiblemente ocupada @ump45nose la tomó hace 10 días. Abiertobug confirmed docs has-pr html v6
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
File input height taller than expectedPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobug confirmed css has-pr v6
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 1 día
Todos los issues de twbs/bootstrap
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
devswha/herdr-web-ui#3325 ·
-
Search fixAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
feat: 插入提示词时默认追加到输入框,长按才替换Abiertoenhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100