CSS

[jrootham]

Convert styling from javascript to CSS files.

[HenrikBechmann]

I think inline styling using generalized tools like radium is getting traction now; more productive and selective and integrated.

But def needs a step up from style attributes everywhere

[bastienvinh]

Is it really a good idea, I would like to ask that to an experimented front-end developer because making their work harder can be fatal for us in the future.

Shouldn't we use what common front-end developer use instead of this? After, all we may have in the future other collaborators. Is it really productive for a lambda front-end?

[jrootham]

I may be a dinosaur, but I tend to use separate css files, with lots of classes and ids.

On Sat, Nov 11, 2017 at 9:35 PM, Bastien VINH notifications@github.com wrote:

Is it really a good idea, I would like to ask that to an experimented front-end developer because making their work harder can be fatal for us in the future.

Shouldn't we use what common front-end developer use instead of this? After, all we may have in the future other collaborators. Is it really productive for a lambda front-end?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/CivicTechTO/budgetpedia-frontend/issues/2#issuecomment-343709174, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5hfR-Kt0JfpphudkZVWjoTMkBO994rks5s1llggaJpZM4Nc1HO .

[HenrikBechmann]

Remember that we're using the material design guidelines, as implemented by material-ui widgets, so most of the styling is taken care of, or can be configured. Beyond that many large projects use Sass or Less for parameterized css. A tool like radium is easier and more flexible, because it doesn't involve precompiling (it uses javascript in-place). Plus it's designed for react components. We're going with components, right? The syntax of radium for the ui professional is familiar (defining simple objects, with extensions).

The main issue is getting a rigorous design = finding a design professional to do that

[HenrikBechmann]

Another lib that gets frequent mention is aphrodite

[bastienvinh]

Well, I've seen web evolving really fast and the thing the new trend always coming. Tomorrow it will be this and this.

One day you will have more and more contributors or maybe you will delegate this project, so it is cool to use generic tools like Saas or Less. Not only that Sass, less has more support tool with the IDE.

If one day, I need to a use a designer tool assistant, Radium is not supported. Not only that, I can't really put easily the CSS as CDN server like Cloudflare. I need to create some hack to the deployment.

CSS file shouldn't be something should be separate to optimize the download of the page. And to be honest, a beginner who will see that :

And this is not simple, it looks like a little complicated :

// Inside render
return (
  <div>
    <button key="keyForButton" style={[styles.button]}>Hover me!</button>
    {Radium.getState(this.state, 'keyForButton', ':hover') ? (
      <span>{' '}Hovering!</span>
    ) : null}
  </div>
);

A CSS file is universal, or Sass / Less is easier to find the skill. Remember this is an open source project and it should target the mass.

[HenrikBechmann]

All to be considered. Another complication is matarial-ui is using CSS in JS https://material-ui-next.com/customization/css-in-js/ they think that's the future, and found using Less was unsatisfactory in the past...

[bastienvinh]

😔 You tried to convince me to another way to re-put the old fashion way, believe me in the past we fight for it.

This is a good article why online style is obsolete: https://css-tricks.com/the-debate-around-do-we-even-need-css-anymore/

The way you code is not new, it's not the future, it is how I use to code with ASP.NET web form. Why should I recompile all the code just to modify one colour? This is absurd. And mixing code this way is not really helpful to focus on the business behaviour of the application, and by this logic, you tried to remove the MVC Pattern too.

[HenrikBechmann]

Not absurd. Lots of well respected toolsets and components use localized styling. The better ones (like material-ui and google charts) allow theming, and local and global over-rides. I doubt localized styling will go away anytime soon. In a componentized world bundling often makes sense.

IAC Less and Sass require their own compilation.

We'll likely end up using a mix of things. Hopefully global styling will be minimized by use of widgets which are already themed :-)

When the time comes we can draw up a list of criteria for methodically making decisions about this and other tool questions. We're still in the prototype phase.

[HenrikBechmann]

BTW I think Flux is a better pattern than MVC -- one way data flow.

[bastienvinh]

Ok

[bastienvinh]

Link: http://jamesknelson.com/why-you-shouldnt-style-with-javascript This article gives me a good idea of why we've never use Inline-style in the first place. The priority of CSS.

CSS is not optimized but I think all modern browser can handle it very well. We should go more to a tool that deletes useless CSS rather than optimizes component.

And using this kind of approach and limit us in using design tooler or recruiting designer. It is not as different as hard-coding a code where you need to rebuild an entire application and redeploy an application just to test a CSS.

Mixing business logic, behaviour logic design logic can be a very disturbing thing when we code. The code, for now, is tiny but it can become complex over time. And that why Angular Approach to create the component is little sexier and simpler.

Not only that, a front-end has better chance to debug faster without any learning curve to debug something in CSS that studying all the application to understand how it is working.

Not only that you have what we call plugin hacking where people prefer to have their own CSS file or CSS styling. Take Facebook or Wikipedia (especially this), for example, you can find some Chrome/Firefox extension to change the look of Facebook. It could be really bad to restraint to one can of possibility and extern CSS has helped us with that. Let them override our atomic class.

The time spending in CSS file and rules is 5 seconds when you need to debug, especially in big projects. How are you going to deal with animation for components easily? How are you going to integrate custom material design made by some people with the inline style?

There is a big chance we will create more debt. And I still don't see the benefit of another layer when the default CSS layer is already good.

Why I should use JSS approach when Adobe Dreamweaver do the same thing and far easier.

Sorry I've gone too far.

[HenrikBechmann]

Thanks @bastienvinh It's a thoughtful article, but I find it unconvincing (for one thing it's disrespectful).

If we really want to do css in react, here are some ways (including component-scoped css). Although with the popularity of inline in the react world we'd have to use !important a lot for third party tools to get precedence.

I don't think switching toolsets or languages to conform to css standards is the right priority. I think the utility of the tools is more important. I really don't want to go back to templates in the angular world! JSX is much easier to reason with.

I really don't think there's a big technical hurdle for devs here either. Everybody knows what inline styles are.

Isolating business and design logic is good. It's one of my goals in refactoring, with clear(er) distinctions between controller and view components. I think this is where we could find common ground. Component-scoped css (particularly our own components) perhaps, and good decoupling of controller and presentation logic. BTW upcoming material-ui components from what I see allow for class-based css (but again, sometimes requiring the !important qualifier)

[HenrikBechmann]

@bastienvinh I've added (and tested) the css-loader to webpack

      {
        test: /\.css$/,
        use: [ 'style-loader', 'css-loader' ]
      }

usage:

import './somestylesheet.css'

That provides stylesheet option...

[bastienvinh]

Maybe I'm little forceful and disrespectful because I already used this approach before (Not a nice idea from my experience). I became evolved to emotionally, sorry.

Typescript makes sense when maybe tomorrow, it will compile web Assembly on a day or another and also have a lot of design pattern possibility. React and Redux is necessary to have a good quality of interaction.

This is what a nobody has to learn from scratch:

• HTML 5
• Javascript + Typescript + React + Redux
• Radium + CSS 3

Radium has his own trick and his own way of debugging that we need to learn for exactly the same result. If you can show how it is very different in the number line of code, the design pattern or any OOCss that it very different from CSS, I can't really fully understand that choice of approach. The only thing different is really the format (and just a little, and you convince me already that exactly the same syntax, that is more confusing). If you use the right IDE or Code Editor, managing 50 files of CSS in a component is a piss of cake. The tool is far more efficient than the approach and it will not impact the repository. And the eyes can be tricky too, the code IDE will mix Javascript. So we write code, the colour syntax will trick us. When CSS is clearly separated from the Javascript code.

Anyway, if you want to go with it. I don't mind.

[HenrikBechmann]

I meant that the author of the article you cited seemed disrespectful.

As mentioned, the use of inline styling is motivated by common usage by useful third party components.

I've found a couple of problems with Radium, so I'm going to phase it out.

As mentioned, with webpack it's easy to use css where we can. Some third party components will require inline though. For our own components it may be convenient in certain cases to bundle the styling. We can let that evolve.

As the css option is available to us, I'm going to close this issue. We can open new issues for particular styling tasks as they come up.