3 ms·

A few (maybe 3) years ago I developed an in-house calendaring webapp and aimed to use the date/time/datetime fields on it. Unfortunately the client couldn't gua

by cmg 10y ago

A few (maybe 3) years ago I developed an in-house calendaring webapp and aimed to use the date/time/datetime fields on it. Unfortunately the client couldn't guarantee browser consistency across their offices, and of course mobile was a concern as well. I don't remember the details and wish I'd written it up, but the inconsistencies across browsers about required values, bounds - not to mention trying to do "trivial" things invalidating Saturdays and Sundays - were astounding. datetime-local helped a bit, but wasn't fully supported in IE. I spent 4 days working on that, then spent an hour ripping my code apart and adding moment.js and the jQuery UI Datepicker widget. At least it worked.

dexwiz 10y ago
+1 for moment.js. Of all the npm modules I have used in the last year, none have been cleaner than moment. It has great docs, all the features you need, and just "works." I am constantly having to come up with workarounds for React, Sequelize, whatever, but momentjs never seems to force me into an awkward position.
- Waterluvian 10y ago
  I'm curious abiut generally speaking what workarounds you're doing in react. Every workaround I've had to do, eventually revealed itself as a code smell or antipattern. Obviously they are there; no view library is perfect. But I have yet to see what one loons like.
  - dexwiz 10y ago
    I would agree most React workarounds are code smells. At one point I had to advise a teammate to not use jQuery to attach event listeners to DOM elements created by React. My major issue is that everything is a component. Which means it's hard to delineate between View and Logic (Models/Controller) code. React rightfully called itself View only. But in classic JS fashion, the community Frankenstiened it into a full framework. Before someone says it, I think stateless functional components are a bad solution to the logic/view separation. Also I don't think React has figured out a good solution for styling yet. The two major camps seem to be inline styles or css classes. We went with css classes so we could use css "frameworks." But I think both methods have their cons.
    - Waterluvian 10y ago
      I agree totally. I have an app of a few hundred components and sometimes there's a lot of heavy business logic that feels wrong to have in a component. I also have this ugly mess of scss that don't live with the components. What I'd like to see is a component gets to define it's own structure and default look and feel. So styles in the component. Then you can give it class information if you're giving it your own styling or customization. I would love to be able to package an entire calendar widget, for example, into a module that is only .JSX files. And know that no matter where I import it, by default it'll look and behave in a sane manner.
      - dexwiz 10y ago
        Using classes as overrides is like how Bootstrap is (was?) customized. Bootstrap had default css classes that applied a default style. To override it, you would create your own css classes with custom attributes targeting the same classes, but with higher specificity [1]. You are still using styling here. Styling can get very verbose. That would just clog up the .JSX file. CSS will be its own entity from React or any templating engine for the foreseeable. Moving it into its own file helps with code organization. The only sane way to link them right now is css classes. Althought the argument for inline versus class css extends beyond the React world. But you have to do things like prefixing to make sure your css [1] https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

by cmg 10y ago

dexwiz 10y ago

+1 for moment.js. Of all the npm modules I have used in the last year, none have been cleaner than moment. It has great docs, all the features you need, and just "works." I am constantly having to come up with workarounds for React, Sequelize, whatever, but momentjs never seems to force me into an awkward position.

Waterluvian 10y ago
I'm curious abiut generally speaking what workarounds you're doing in react. Every workaround I've had to do, eventually revealed itself as a code smell or antipattern. Obviously they are there; no view library is perfect. But I have yet to see what one loons like.
- dexwiz 10y ago
  I would agree most React workarounds are code smells. At one point I had to advise a teammate to not use jQuery to attach event listeners to DOM elements created by React. My major issue is that everything is a component. Which means it's hard to delineate between View and Logic (Models/Controller) code. React rightfully called itself View only. But in classic JS fashion, the community Frankenstiened it into a full framework. Before someone says it, I think stateless functional components are a bad solution to the logic/view separation. Also I don't think React has figured out a good solution for styling yet. The two major camps seem to be inline styles or css classes. We went with css classes so we could use css "frameworks." But I think both methods have their cons.
  - Waterluvian 10y ago
    I agree totally. I have an app of a few hundred components and sometimes there's a lot of heavy business logic that feels wrong to have in a component. I also have this ugly mess of scss that don't live with the components. What I'd like to see is a component gets to define it's own structure and default look and feel. So styles in the component. Then you can give it class information if you're giving it your own styling or customization. I would love to be able to package an entire calendar widget, for example, into a module that is only .JSX files. And know that no matter where I import it, by default it'll look and behave in a sane manner.
    - dexwiz 10y ago
      Using classes as overrides is like how Bootstrap is (was?) customized. Bootstrap had default css classes that applied a default style. To override it, you would create your own css classes with custom attributes targeting the same classes, but with higher specificity [1]. You are still using styling here. Styling can get very verbose. That would just clog up the .JSX file. CSS will be its own entity from React or any templating engine for the foreseeable. Moving it into its own file helps with code organization. The only sane way to link them right now is css classes. Althought the argument for inline versus class css extends beyond the React world. But you have to do things like prefixing to make sure your css [1] https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity