Como sé, todavía no hay patrones específicos para Javascript. Pero creo que hay un potencial para algo como el enfoque de widgets (componentes). Dado que principalmente utilizamos javascript para potenciar nuestro código html. Es lógico que debemos conectar todos nuestros objetos javascript a la etiqueta html. Entonces aquí tenemos algo como Model (jsObject) + View (HTMLrepresentation). Para obtener MVC necesitamos controladores y tenemos eventos para esto. En este caso, habremos encapsulado fácilmente el componente extensibel.
por ejemplo:
// this is a part of some FormValid.js
<script>
function FormValid(){
}
FormValid.prototype.validate=function(){...}
</script>
//this is our HTML
<form id="form1"...onsubmit="this.jsObject.validate();">
</form>
<script>
//all the following stuff could be solved in one line, but you need to create some helper. Like Components.Attach("FormValid").to("form1");
var newObj=new FormValid()
var form=document.getElementById("form1");
from.jsObject=newObj;
newObj.htmlObj=form;
</script>
También tengo una idea de usar motores de plantilla como Zparser para separar la vista y el modelo. Estoy desarrollando una biblioteca js para esto, así que estoy en esta pregunta ahora mismo.
Tenemos objeto central con método de la vista. Todas nuestras clases lo tienen como un prototipo al final. Este método obtiene plantillas propiedad de la clase y el uso de algunas plantillas de analizador genera HTML basándose en nuestro modelo. Este HTML se inserta en el nodo htmlObj para que se actualice la VISTA de nuestro objeto. Esto es básicamente una idea y nuestro código se convierte en:
// this is a part of some FormValid.js
<script>
function FormValid(){
}
Components.extendCore(FormValid);
FormValid.prototype.validate=function(){...}
</script>
FormValid.prototype.templates={
main:'<form class="form1"...onsubmit="this.jsObject.validate();">...</form>'
}
//this is our HTML
<div id="form1"></div>
<script>
Components.Attach("FormValid").to("form1");
</script>
todavía creo última línea <script> debería estar allí y no es la mezcla de la lógica con la representación porque se trata de componentes - pieza sólida. No tiene sentido uno sin otro. En realidad, esto debería ser parte de la aplicación. Algo como html of component (en las un ejemplo es div) debe definirse y envolverse con un componente que agregará automáticamente scripts e id.
Ahora. Te mostré 2 ejemplos y explicaré por qué el segundo es demasiado específico.
Todo está en accesibilidad y rendimiento (y pérdidas de memoria). Si va a actualizar todo el html del componente con frecuencia, parpadeará, también necesitará volver a configurar todos los eventos dinámicos y verificar si hay fugas de memoria. Pero el problema principal si JS falla, su aplicación no mostrará nada.
Así que prefiero tener la opción entre los dos :) y usar todo en sus lugares.
no hay ninguna razón por la cual MV [C | P] no debería aplicarse, es un lenguaje bonito e independiente. – Chii