Post pobrano z: Scaling CSS: Two Sides of a Spectrum

The subject of scaling CSS came up a lot in a recent ShopTalk Show with Ben Frain. Ben has put a lot of thought into the subject, even writing a complete book on it, Enduring CSS, which is centered around a whole ECSS methodology.

He talked about how there are essentially two solutions for styling at scale:

1. Total isolation
2. Total abstraction

Total isolation is some version of writing styles scoped to some boundary that you’ve set up (like a component) in which those styles don’t leak in or out.

Total abstraction is some version of writing styles that are global, yet so generic and re-usable, that they have no unintended side effects.

Total isolation might come from <style scoped> in a .vue file, CSS modules in which CSS class selectors and HTML class attributes are dynamically generated gibberish, or a CSS-in-JS project, like glamerous. Even strictly-followed naming conventions like BEM can be a form of total isolation.

Total abstraction might come from a project, like Tachyons, that gives you a fixed set of class names to use for styling (Tailwind is like a configurable version of that), or a programmatic tool (like Atomizer) that turns specially named HTML class attributes into a stylesheet with exactly what it needs.

It’s the middle ground that has problems. It’s using a naming methodology, but not holding strictly to it. It’s using some styles in components, but also having a global stylesheet that does random other things. Or, it’s having lots of developers contributing to a styling system that has no strict rules and mixes global and scoped styles. Any stylesheet that grows and grows and grows. Fighting it by removing some unused styles isn’t a real solution (and here’s why).

Note that the web is a big place and not all projects need a scaling solution. A huge codebase with hundreds of developers that needs to be maintained for decades absolutely does. My personal site does not. I’ve had my fair share of styling problems, but I’ve never been so crippled by them that I’ve needed to implement something as strict as Atomic CSS (et al.) to get work done. Nor at at any job I’ve had so far. I see the benefits though.

Imagine the scale of Twitter.com over a decade! Nicolas has a great thread where he compares Twitter’s PWA against Twitter’s legacy desktop website.

The legacy site’s CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can’t be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers alike.

The post Scaling CSS: Two Sides of a Spectrum appeared first on CSS-Tricks.

Post pobrano z: GraphQL is Everywhere!

I find GraphQL extremely fun and empowering tech to work with, even as a novice just getting started. You’ve probably heard the elevator pitch before: it allows you to ask for exactly the data you need whenever you need it (probably at the component level), and it arrives as lovely JSON data for your usage.

I see it used as part of modern website builds all the dang time. The overall vibe is, „I want to do whatever I want on the front end, and that actually allows for more back-end choices as well.” And by „whatever” on the front end, that generally means a fancy SPA-ish JavaScript-powered thing or a static-site generator-ish thing.

Here’s a quick smattering of articles that are everywhere these days. Instead of the actual article titles, I’ll rename with the stack parts.

• Contentful > GraphQL
• Contentful > GraphQL > Gatsby
• Another Contentful > GraphQL > Gatsby
• CraftCMS > GraphQL
• Craft CMS > GraphQL > Headless site
• CraftCMS > GraphQL > Vue
• GraphQL > 11ty
• WordPress > GraphQL
• WordPress.com > GraphQL > Gatsby
• WordPress.org > GraphQL > Gatsby
• WordPress > GraphQL > Vue
• Drupal > GraphQL
• GraphCMS > GraphQL
• DatoCMS > GraphQL
• DatoCMS > GraphQL > Vue/Nuxt
• CosmicJS > GraphQL
• GravCMS > Gatsby > GraphQL
• Strapi > GraphQL > Gatsby
• Netlify CMS > Gatsby > GraphQL
• Gentics Mesh > GraphQL
• Relax > GraphQL (maybe dead?)
• Jekyll > GraphQL
• TakeShape > GraphQL

GraphQL is certainly in the new-and-hip category, but as ever, everything old is new again. Check out Query by Example, a language from the 1970’s:

.....Name: Bob
..Address:
.....City:
....State: TX
..Zipcode:

Resulting SQL:

SELECT * FROM Contacts WHERE Name='Bob' AND State='TX';

The post GraphQL is Everywhere! appeared first on CSS-Tricks.

Post pobrano z: GraphQL is Everywhere!

I find GraphQL extremely fun and empowering tech to work with, even as a novice just getting started. You’ve probably heard the elevator pitch before: it allows you to ask for exactly the data you need whenever you need it (probably at the component level), and it arrives as lovely JSON data for your usage.

I see it used as part of modern website builds all the dang time. The overall vibe is, „I want to do whatever I want on the front end, and that actually allows for more back-end choices as well.” And by „whatever” on the front end, that generally means a fancy SPA-ish JavaScript-powered thing or a static-site generator-ish thing.

Here’s a quick smattering of articles that are everywhere these days. Instead of the actual article titles, I’ll rename with the stack parts.

• Contentful > GraphQL
• Contentful > GraphQL > Gatsby
• Another Contentful > GraphQL > Gatsby
• CraftCMS > GraphQL
• Craft CMS > GraphQL > Headless site
• CraftCMS > GraphQL > Vue
• GraphQL > 11ty
• WordPress > GraphQL
• WordPress.com > GraphQL > Gatsby
• WordPress.org > GraphQL > Gatsby
• WordPress > GraphQL > Vue
• Drupal > GraphQL
• GraphCMS > GraphQL
• DatoCMS > GraphQL
• DatoCMS > GraphQL > Vue/Nuxt
• CosmicJS > GraphQL
• GravCMS > Gatsby > GraphQL
• Strapi > GraphQL > Gatsby
• Netlify CMS > Gatsby > GraphQL
• Gentics Mesh > GraphQL
• Relax > GraphQL (maybe dead?)
• Jekyll > GraphQL
• TakeShape > GraphQL

GraphQL is certainly in the new-and-hip category, but as ever, everything old is new again. Check out Query by Example, a language from the 1970’s:

.....Name: Bob
..Address:
.....City:
....State: TX
..Zipcode:

Resulting SQL:

SELECT * FROM Contacts WHERE Name='Bob' AND State='TX';

The post GraphQL is Everywhere! appeared first on CSS-Tricks.

Post pobrano z: An Overview of Render Props in React

An Overview of Render Props in React

Using render props in React is a technique for efficiently re-using code. According to the React documentation, „a component with a render prop takes a function that returns a React element and calls it instead of implementing its own render logic.” To understand what that means, let’s take a look at the render props pattern and then apply it to a couple of light examples.

The render props pattern

In working with render props, you pass a render function to a component that, in turn, returns a React element. This render function is defined by another component, and the receiving component shares what is passed through the render function.

This is what this looks like:

class BaseComponent extends Component {
  render() {
    return <Fragment>{this.props.render()}</Fragment>;
  }
}

Imagine, if you will, that our App is a gift box where App itself is the bow on top. If the box is the component we are creating and we open it, we’ll expose the props, states, functions and methods needed to make the component work once it’s called by render().

The render function of a component normally has all the JSX and such that form the DOM for that component. Instead, this component has a render function, this.props.render(), that will display a component that gets passed in via props.

Example: Creating a counter

See the Pen React Render Props by Kingsley Silas Chijioke (@kinsomicrote) on CodePen.

Let’s make a simple counter example that increases and decreases a value depending on the button that is clicked.

First, we start by creating a component that will be used to wrap the initial state, methods and rendering. Creatively, we’ll call this Wrapper:

class Wrapper extends Component {
  state = {
    count: 0
  };

  // Increase count
  increment = () => {
    const { count } = this.state;
    return this.setState({ count: count + 1 });
  };

  // Decrease count
  decrement = () => {
    const { count } = this.state;
    return this.setState({ count: count - 1 });
  };

  render() {
    const { count } = this.state;

    return (
      <div>
        {this.props.render({
          increment: this.increment,
          decrement: this.decrement,
          count: count
        })}
      </div>
    );
  }
}

In the Wrapper component, we specify the methods and state what gets exposed to the wrapped component. For this example, we need the increment and decrement methods. We have our default count set as 0. The logic is to either increment or decrement count depending on the method that is triggered, starting with a zero value.

If you take a look at the return() method, you’ll see that we are making use of this.props.render(). It is through this function that we pass methods and state from the Wrapper component so that the component that is being wrapped by it will make use of it.

To use it for our App component, the component will look like this:

class App extends React.Component {
  render() {
    return (
      <Wrapper
        render={({ increment, decrement, count }) => (
          <div>
            <div>
              <h3>Render Props Counter</h3>
            </div>
            <div>
              <p>{count}</p>
              <button onClick={() => increment()}>Increment</button>
              <button onClick={() => decrement()}>Decrement</button>
            </div>
          </div>
        )}
      />
    );
  }
}

Example: Creating a data list

The gain lies in the reusable power of render props, let’s create a component that can be used to handle a list of data which is obtainable from an API.

See the Pen React Render Props 2 by Kingsley Silas Chijioke (@kinsomicrote) on CodePen.

What do we want from the wrapper component this time? We want to pass the source link for the data we want to render to it, then make a GET request to obtain the data. When the data is obtained we then set it as the new state of the component and render it for display.

class Wrapper extends React.Component {
  state = {
    isLoading: true,
    error: null,
    list: []
  };

  fetchData() {
    axios.get(this.props.link)
      .then((response) => {
        this.setState({
          list: response.data,
          isLoading: false
        });
    })
    .catch(error => this.setState({ error, isLoading: false }));
  }

  componentDidMount() {
    this.setState({ isLoading: true }, this.fetchData);
  }

  render() {
    return this.props.render(this.state);
  }
}

The data link will be passed as props to the Wrapper component. When we get the response from the server, we update list using what is returned from the server. The request is made to the server after the component mounts.

Here is how the Wrapper gets used:

class App extends React.Component {
  render() {
    return (
      <Wrapper
        link="https://jsonplaceholder.typicode.com/users"
        render={({ list, isLoading, error }) => (
          <div>
            <h2>Random Users</h2>
            {error ? <p>{error.message}</p> : null}
            {isLoading ? (
              <h2>Loading...</h2>
            ) : (
              <ul>{list.map(user => <li key={user.id}>{user.name}</li>)}</ul>
            )}
          </div>
        )}
      />
    );
  }
}

You can see that we pass the link as a prop, then we use ES6 de-structuring to get the state of the Wrapper component which is then rendered. The first time the component loads, we display loading text, which is replaced by the list of items once we get a response and data from the server.

The App component here is a class component since it does not manage state. We can transform it into a functional stateless component.

const App = () => {
  return (
    <Wrapper
      link="https://jsonplaceholder.typicode.com/users"
      render={({ list, isLoading, error }) => (
        <div>
          <h2>Random Users</h2>
          {error ? <p>{error.message}</p> : null}
          {isLoading ? (
            <h2>Loading...</h2>
          ) : (
            <ul>{list.map(user => <li key={user.id}>{user.name}</li>)}</ul>
          )}
        </div>
      )}
    />
  );
}

That’s a wrap!

People often compare render props with higher-order components. If you want to go down that path, I suggest you check out this post as well as this insightful talk on the topic by Michael Jackson.

The post An Overview of Render Props in React appeared first on CSS-Tricks.