Aunque hay muchas formas de escribir estilos cuando trabajamos con React.js, es bastante habitual usar Sass, que no es más que CSS con superpoderes, para escribir las hojas de estilos pero que requieren de una pequeña librería para compilar lo que hemos escrito en reglas CSS puras. Es aquí donde entraba el archiconocido node-sass que tantos quebraderos de cabeza solía dar, pero…
Aunque el concepto de React.JS y Web Components es muy parecido en el fondo, crear componentes reutilizables, resuelven problemas diferentes porque se aplican a contextos muy distinto ya que, Web Components se basa en crear mini-componentes que puedan ser incrustados en cualquier desarrollo web y en React.JS se crean componentes que pueden ser reutilizados dentro de cualquier desarrollo con React. Pero ¿es posible mezclar ambos mundos? La respuesta es sí, y además de una forma muy sencilla.
Algo habitual cuando diseñamos una página es tener que dibujar triángulos y siempre andamos rebanándonos los sesos hasta que, cansados, creamos una imagen con el triángulo deseado y así nos evitamos más quebraderos de cabeza, pero, ¿es óptimo?
Cuando usamos imágenes tenemos los siguientes problemas
Con CSS podemos jugar con los bordes o con el efecto :after de los elementos para dibujar triángulos a nuestro antojo, reduciendo el procesado del navegador y permitiéndonos cambiarle la forma, el tamaño y el color según nos convenga con lo que se convierte en la solución más óptima.
En este artículo escribiré un truco sencillo para leer la extensión de un fichero mediante JavaScript pensando, no sólo en conocer dicha extensión, sino además en guardarla en una variable para poder realizar acciones como agregar un icono, emparejarlo con una clase de CSS, etc.
Cuando desarrollamos Display Templates para dar un look&feel diferente a los elementos resultantes de las búsquedas en SharePoint, muchas veces es necesario ejecutar código JavasScript tras la carga de los mismos ya sea para añadir funcionalidad extra o simplemente para establecer algunas propiedades visuales que requieran de conocer los resultados para mostrar una mejor distribución.
Hace algunos días me encontré con un problema en Safari al establecer fechas con un datepicker de Metro UI que es el mismo que el que corresponde a jQuery UI datepicker. El problema se producía al seleccionar una fecha que, al realizarse la validación con jQuery.validation decía que era incorrecta al contrario que en el resto de navegadores (Internet Explorer, Microsoft Edge, Google Chrome*, Firefox y Opera). Además, parece que el error se reproducía en Google Chrome para Mac lo que hacía más complicado determinar cuál es el problema. Como se puede apreciar en la imagen, tiene problemas al establecer fechas predefinidas como en el campo «inicio» en el que he puesto la fecha actual (tanto desde el modelo como con JavaScript) y, en el campo «Vencimiento» la fecha seleccionada con el datepicker genera un error de validación «incomprensible»
Hasta ahora en Visual Studio disponíamos de una herramienta que nos hacía prácticamente todo el trabajo «engorroso» a la hora de trabajar en el frontend de una aplicación, Web Essentials, pero en la versión para Visual Studio 2015 han anunciado que no incluirían la característica que más uso yo hoy en día de esta herramienta y no es otra que el compilador de SASS
así que, nos va a tocar hacerlo a mano haciendo uso de
Gulp o Grunt.
Llega una nueva entrega de «Fantasmas del código» y, en esta ocasión le toca a SharePoint 2013 y los problemas con jQuery.
Cuando tenemos que personalizar un sitio de SharePoint 2013 es muy probable que hagamos uso de jQuery, plugins, etc… y así dotarlo de «vida» y de nuevas funcionalidades que no vienen por defecto y que queremos añadir en nuestros Web Parts, User Controls, Display Templates, Page Layouts,… y, como todo el mundo sabe, la mejor forma realizar llamadas jQuery es usando el alias «$» como por ejemplo cuando queremos que nuestro código se ejecute cuando la página esté lista.
Llega una nueva entrega de «Fantasmas del código» y, en esta ocasión le toca a SharePoint 2013 y los problemas con jQuery.
Cuando tenemos que personalizar un sitio de SharePoint 2013 es muy probable que hagamos uso de jQuery, plugins, etc… y así dotarlo de «vida» y de nuevas funcionalidades que no vienen por defecto y que queremos añadir en nuestros Web Parts, User Controls, Display Templates, Page Layouts,… y, como todo el mundo sabe, la mejor forma realizar llamadas jQuery es usando el alias «$» como por ejemplo cuando queremos que nuestro código se ejecute cuando la página esté lista.
Estos días he tenido la necesidad de trabajar con un formulario de subida de imágenes y he tenido que montar una zona para mostrar la preview de las imágenes antes de subirlas al servidor para que el usuario pueda comprobar si todo es correcto antes de completar la operación. Hace algún tiempo (algunos años) creo recordar que vi alguna respuesta del gran Pedro Hurtado en los foros de MSDN acerca de esta cuestión pero no he podido encontrar dónde lo vi. Así que lo posteo para intentar ayudar a quien se encuentre en este caso y no sepa cómo alcanzar la solución.