DEV Community: Radoslav Stankov

Building AutoLink component in React

Radoslav Stankov — Fri, 21 Aug 2020 11:42:31 +0000

I had to implement a React component which takes text and adds links to the detected URLs:

<AutoLink>
  This text contains link to http://example.com and https://example.com
</AutoLink>

This generates the following HTML:

<p>
  This text contains link to <a href="http://example.com" target="_blank">http://example.com</a> and <a href="https://example.com" target="_blank">https://example.com</a>
</p>

In order to build this component, I had to use а little know feature of the String.prototype.split method. Most people know that if you have the following string a,c,d,e you can split it by ,, you get an array:

"a,b,c".split(/,/) // => ["a", "b", "c"]

Today I learned, that you can actually include the separator in the results:

"a,b,c".split(/(,)/) // => ["a", ",", "b", ",", "c"]

This uses the regular expression group feature.

Using this feature, I created a mapLinks function. It takes the text and yields the links it detects.

const EXP = /(https?:\/\/(?:www\.|(?!www))[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\.[^\s]{2,}|www\.[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\.[^\s]{2,}|https?:\/\/(?:www\.|(?!www))[a-zA-Z0-9]+\.[^\s]{2,}|www\.[a-zA-Z0-9]+\.[^\s]{2,})/gi; 

export function mapLinks(text, fn)) {
  // this splits the text, by links but it still keeps those links in the result
  return text.split(EXP).map((chunk, i) => {
    if (chunk.match(EXP)) {
      return fn(chunk, i);
    }

    return chunk;
  });

Then I just used this function for the component itself:

export default React.memo(({ children }) => (
  <p>
    {mapLinks(children, (url, i) => (
      <a href={url} target="_blank" key={i}>
        {url}
      </a>
    ))}
  </p>
)}

How I use React.Context

Radoslav Stankov — Tue, 18 Aug 2020 07:40:06 +0000

I get a lot of questions about how I'm using React.Context. A lot of people overuse it, and their applications become messy.

I've had several conversations like the following:

[someone]: I don't use React.Context. It makes my application quite disjointed (or some more colorful term), I just use Redux or Apollo.
[me]: They both use React.Context under the hood.
[someone]: Yes, but this is an implementation detail, I don't use the context directly.
[me]: That's exactly how you should use React.Context -- as an implementation detail. Then you build an API on top of it and don't touch the context directly.

One example is YourStack's toast system.

This is how it looks:

As a developer, you are going to use it like this:

import { useToast } from '~/utils/toast'

function ShowToast() {
  const open = useToast();

  const onClick = () => open({
    icon: '🚨',
    title: 'This is the title for this prompt',
    content: <strong>Content</strong>,
  });

  return <button onClick={onClick}>open</button>;
}

The setup looks like this:

import { ToastProvider } from '~/utils/toast'

// the "Provider" pyramid
<ApolloProvider>
  <ToastProvider>
    <ModalProvider>
        <Layout>
          {children}
        </Layout>
        // notice those .Content components
        // having those allow us to show toast message from modal and open modal from a toast message
        // (look below for implemenation)
        <ModalProvider.Content />
        <ToastProvider.Content />
    </ModalProvider>
    </ToastProvider>
</ApolloProvider>

Only openToast and ToastProvider are exposed in the public API of the toast system. There is no mention of React.Context.

Here is the implementation of the toast system:

interface IToastOptions {
  title: string;
  icon?: string | React.ReactNode;
  type?: 'notice' | 'success' | 'alert';
  // We support content that can be
  // - text
  // - React node
  // - any function with a "close" callback that returns a React node
  content?: string | React.ReactNode | ((close: () => void) => React.ReactNode);
}

interface IToast extends IToastOptions {
  id: number;
}

// the actual context contains
// not only the toast object, but
// also the helper functions to manage it
// (those aren't accessible outside the module)
interface IToastContext {
  toast: IToast | null;
  open: (toast: IToastOptions) => void;
  close: () => void;
}

const ToastContext = React.createContext<IToastContext>({
  toast: null,
  open() {},
  close() {},
});

// each toast get an unique ID, so key={toast.id} triggers re-render
let uid = 0;

export function ToastProvider({ children }: { children: React.ReactNode }) {
  // this is a popular pattern when using contexts
  // having a state of root component passed to the context
  const [toast, setToast] = React.useState<IToast | null>(null);

  // because the actual context value is not a simple object
  // we cache it, so it doesn't trigger re-renderings
  const contextValue = React.useMemo(
    () => ({
      toast,
      open(value: IToastOptions) {
        // this is the small "hack" to get unique ids
        setToast({ ...value, type: value.type || 'notice', id: uid += 1 });
      },
      close() {
        setToast(null);
      },
    }),
    [toast, setToast],
  );

  return (
    <ToastContext.Provider value={contextValue}>
      {children}
    </ToastContext.Provider>
  );
}


// initially this was just inlined in "ToastProvider"
// however, we needed to integrate with our modal system
// and we needed to be explicit about where the toasts are rendered
ToastProvider.Content = () => {
  const context = React.useContext(ToastContext);

  if (!context.toast) {
    return null;
  }

  return (
    <Toast
      key={context.toast.id}
      toast={context.toast}
      close={context.close}
    />
  );
};

export function useToast() {
  return React.useContext(ToastContext).open;
}

interface IToastProps {
  toast: IToast;
  close: () => void;
}

function Toast({ toast, close }: IToastProps) {
  // UI for the toast
  // just regular component
}

Couple of things to notice:

ToastProvider is managing the state
it passes helpers and state down the tree and hides the "real" context
the "real" context is inaccessible from outside
you can only show a toast via useToast

Now, imagine having to implement some of the following features:

New UI for the toast messages
Stacking of toast messages - showing multiple toasts on the screen
Hide toast messages after a timeout

Those would be quite easy to implement, barely an inconvenience, because everything is encapsulated.

In YourStack, we only have 3 instances of React.Context (written by my team) - toast, modal, moderation systems. Notice the word "systems". They are all isolated as if they were 3rd party libraries. ProductHunt is the same.

Our modal system has a similar API. It has many more features like code-split, GraphQL fetching, loading, error handling, themes, nesting, and URLs. It deserves its own blog post someday.

Conclusion

React.Context is useful and should be used with care. We shouldn't reach for it just because we're too lazy to pass properties around.
My advice is to encapsulate its uses as if they are 3rd party libraries and have clear APIs for this. Don't go overboard.

If you have any questions or comments, you can ping me on Twitter.

Extract React Hook Refactoring

Radoslav Stankov — Fri, 07 Aug 2020 10:55:06 +0000

I consider it a code smell when a React functional component has more than 5 lines before its return statement.

Whenever I see this, I immediately start to think about ways to clean this up.

I often use custom React hooks to encapsulate logic and have clear boundaries in my code.

One thing I've noticed is that people are quite hesitant to create custom hooks.

They think that hooks are somehow magical, and it is dangerous to create your own.
Hooks are just functions. Yes, some of the build-in React ones are connected to internals, but still, they are meant to be composed.

Other arguments I have heard against extracting custom hooks are: "I just need this in one place, no need to make it reusable".
Custom hooks can be reusable, but this is not a requirement.

React pushes people to write composable code, which is excellent. But due to having markup in our functions, we get used to long functions.

When you write Ruby, and you have a method which is more than 5-10 lines long, you start thinking about how to split it up and make it more understandable.
This is definitely not true in JavaScript and especially when we write React components, which is a shame. 🤷‍♂️

Why is having a lot of code in one function problematic?

It makes it hard to understand this code. Usually, it hides the connection between the different areas in the code.

The following code is simplified extract from a Pull Request for a new feature of YourStack. We are building a question box with the ability to go to the next or the previous question.

export default function QuestionCard() {
  const [endCursors, setEndCursors] = React.useState([]);

  const { data, refetch, variables } = useQuery(QUERY, {
    variables: { cursor: null },
  });
  if (!data) {
    return null;
  }

  const { questions } = data;
  const question = get(questions, 0);
  if (!question) {
      return null;
  }

  const { endCursor, hasNextPage } = questions.pageInfo;
  const hasPrevious = endCursors.length > 0;

  return (
    <Card>
      {/* code */}
      <Button
        label="previous"
        disabled={!hasPrevious}
        onClick={() => {
          const cursor = endCursors.pop();
          refetch({ cursor });
          setEndCursors(endCursors);
        }}
      />
      <Button
        label="next"
        disabled={!hasNextPage}
        onClick={() => {
          refetch({ cursor: endCursor });
          setEndCursors([...endCursors, variables.cursor || '']);
        }}
      />
      {/* code */}
      <Form.Mutation
        mutation={SUBMIT_FROM}
        onSubmit={() => {
          refetch({ cursor: endCursor });
          setEndCursors([...endCursors, variables.cursor || '']);
        }}>
        {/* code */}
      </Form.Mutation>
      {/* code */}
    </Card>
  );
}

It is quite long. Let's refactor it. 🧐

I would like the whole thing to be a single hook. However, when I refactor, I do it step by step.

First, I will create my new hook useCardQuestion. I usually start with extracting the interface and then implement it. I don't try to make it "pretty", I just try to put everything together.

export default function QuestionCard() {
  const [endCursors, setEndCursors] = React.useState([]);

  // our new hook
  // notice how akward passing both question and questions is
  const { question, questions, refetch } = useQuestionCard()

  // notice we guard agains missing data
  if (!question) {
    return null;
  }

  const { endCursor, hasNextPage } = questions.pageInfo;
  const hasPrevious = endCursors.length > 0;

   // ... rest of the code

The hook itself looks like this:

function useQuestionCard() {
  const { data, refetch, variables } = useQuery(QUERY, {
    variables: { cursor: null },
  });

  if (!data) {
    // it is okay to return empty object here
    // when data is not ready shouldn't be able todo anything.
    return {};
  }

  const questions = questions;

  return { question: get(data.questions, 0), questions, refetch };
}

Next, as mentioned earlier, "notice how awkward passing both question and questions is". The only reason we need the questions is so we can "interrogate" it for the next question logic. We will deal with this in a bit.

Very often, I notice people being more comfortable having function definitions inside a component prop. This often (like in this case) leads to defining the same function twice. It makes it harder to refactor into custom hooks because it seems like every local variable is needed somewhere.

Let's move the custom functions:

export default function QuestionCard() {
  // ... code
  const { endCursor, hasNextPage } = questions.pageInfo;
  const hasPrevious = endCursors.length > 0;

  const nextQuestion = () => {
    refetch({ cursor: endCursor });
    setEndCursors([...endCursors, variables.cursor || '']);
  };

  const previousQuestion = () => {
    const cursor = endCursors.pop();
    refetch({ cursor });
    setEndCursors(endCursors);
  };

  return (
    <Card>
      {/* code */}
      <Button
        label="previous"
        disabled={!hasPrevious}
        onClick={previousQuestion}
      />
      <Button 
        label="next" 
        disabled={!hasNextPage} 
        onClick={nextQuestion} />
      {/* code */}
      <Form.Mutation mutation={SUBMIT_FROM} onSubmit={nextQuestion}>
        {/* code */}
      </Form.Mutation>
      {/* code */}
    </Card>
  );
}

When you refactor your code, you start noticing data dependencies.
In this case, when hasPrevious and hasNextPage are false, we don't need the functions to be defined at all.

Our final version looks like this:

export default function QuestionCard() {
  const { question, previousQuestion, nextQuestion } = useQuestionCard();

  if (!question) {
    return null;
  }

  return (
    <Card>
      {/* code */}
    </Card>
  );
}

This is how the useQuestionCard hook looks like

function useQuestionCard() {
  const [endCursors, setEndCursors] = React.useState([]);
  const { data, refetch, variables } = useQuery(QUERY, {
    variables: { cursor: null },
  });

  if (!data) {
    return {};
  }

  const questions = data.questions;

  const nextQuestion = questions.pageInfo.hasNextPage
    ? () => {
        refetch({ cursor: questions.pageInfo.endCursor });
        setEndCursors([...endCursors, variables.cursor || '']);
      }
    : null;

  const previousQuestion = endCursors.length > 0 ? () => {
    const cursor = endCursors.pop();
    refetch({ cursor });
    setEndCursors(endCursors);
  } : null;

  return {
    question: get(data.questions, 0),
    nextQuestion,
    previousQuestion,
  };
}

I like the final version a lot more.

Testing

One benefit of custom hooks, I didn't mention is testing. Custom hooks make testing your code a lot easier since you can test them in isolation.

I'm working on a separate blog post to cover this subject.

Conclusion

Initially, hooks looked quite weird to me. Nowadays, I see them as a great tool to make my code a lot more understandable.

Try grouping logic into custom hooks every time you see the usage of multiple hooks in your component.

If you have any questions or comments, you can ping me on Twitter.

Testing GraphQL Backend in Product Hunt

Radoslav Stankov — Tue, 04 Aug 2020 13:03:25 +0000

People don't write tests because it takes too much time to write them. They lose a lot of mental energy on answering trivial questions like "Do we test this in our application?", "Should I test this?", "How do I test this?", "How do I set up my test", and so on.

For your team to write tests, your team members need two things: good conventions on how and what to test, and good tooling.

I spend a lot of time making the common use-cases easy to test. In Product Hunt, one such example is our Ruby GraphQL testing helpers.

We test three categories of GraphQL API code.

Helpers
Mutation classes
Resolver classes

Helpers

Those are helper module and classes like RecordLoader / RequestInfo / Context / RateLimiter and others. We don't have many of those. They are regular Ruby objects and are tested as such.

Mutations

Mutations in GraphQL are the operations that change your data. It is very, very important for those to be fully tested.

For each mutation, we test:

Authentication and authorization rules
Failure cases - validation, errors
Happy paths

Mutations inherit from Mutations::BaseMutation class. I have written a blog post on the topic - here

Here is an example mutation:

module Mutations
  class QuestionCreate < BaseMutation
    argument :title, String, required: false

    authorize :create, Question

    returns Types::QuestionType

    def perform(attributes)
      question = Question.new(user: current_user)
      question.update(attributes)
      question
    end
  end
end

The way to test this, without extra tooling is:

describe Mutations::QuestionCreate do
  let(:user) { create :user }

  it 'creates a question' do
    context = Graph::Context.new(
      query: OpenStruct.new(schema: StacksSchema),
      values: context.merge(current_user: user),
      object: nil,
    )

    result = described_class.new(object: nil, context: context, field: nil).resolve(
      title: 'What email client do you use?',
    )

    expect(result[:errors]).to eq []
    expect(result[:node]).to have_attributes(
      id: be_present,
      user: user,
      title: 'What email client do you use?',
    )
  end
end

Yikes! 🥶 Having to write something like this for every mutation will put off even the most enthusiastic developers.

The graphql-ruby classes aren't designed to be instantiated and run by you. The gem itself does this. Thus running them requires a lot of orchestration. That's why we have custom helpers to test mutations.

We have a custom helpers to test mutations.

Here is the updated example:

describe Mutations::QuestionCreate do
  let(:user) { create :user }

  it 'requires an user' do
    # executes the mutation with one-liner
    result = execute_mutation(
      title: 'test',
    )

    # verify that mutation returned this error
    expect_access_denied_error(result)
  end

  it 'creates a question' do
    # the one-liner, allow us to specify current user
    result = execute_mutation(
      current_user: user,
      title: 'What email client do you use?',
    )

    # "expect_node" verify that:
    # 1. there are no errors
    # 2. "node" is not null
    expect_node(result) do |node|
      expect(node).to have_attributes(
        id: be_present,
        user: user,
        title: 'What email client do you use?',
      )
    end
  end

  it 'requires a title' do
    result = execute_mutation(
      current_user: user,
      title: '',
    )

    # "expect_error" verify that:
    # 1. "node" is nil
    # 2. there is an error for given attribute and message
    expect_error result, :title, :blank
  end
end

This is a lot better. It clearly communicates what the business logic of this mutation is.

Here, you can find the gist of those helper methods.

Resolvers

Resolvers inherit from GraphQL::Schema::Resolver. They help us structure the code and make it easier to test. The alternative is to write the logic in the type classes. We tend to avoid this because classes get bloated and are harder to test.

The following is an example of a resolver that tells us if the logged-in user has liked a given object:

class Resolvers::IsLiked < Resolvers::Base
  type Boolean, null: false

  def resolve
    current_user = context.current_user
    return false if current_user.blank?

    Graph::IsLoaderPolymorphic.for(current_user.likes).load(object)
  end
end

Note: Graph::IsLoaderPolymorphic is batching helper. I have written about batching in GraphQL - here and here.

How will we test this?

We have two helpers for testing resolvers: execute_resolver and execute_batch_resolver.

describe Resolvers::IsLiked do
  let(:user) { create :user }
  let(:answer) { create :answer }

  def expect_call(object:, user:)
    expect(execute_batch_resolver(current_user: user, object: object))
  end

  it 'returns false when there is no user' do
    expect_call(object: answer, user: nil).to eq false
  end

  it 'returns false when the user has not liked the answer' do
    expect_call(object: answer, user: user).to eq false
  end

  it 'returns true when the user has liked the answer' do
    create: like, subject: answer, profile: user.profile

    expect_call(object: answer, user: user).to eq true
  end
end

Here, you can find the gist of those helper methods.

Conclusion

Test helpers can make testing more accessible. Our GraphQL helpers are just one example of this. People should think about the domain they are testing, not about test boilerplate.

If you have any questions or comments, you can ping me on Twitter.

Building AutoLink component in React

Radoslav Stankov — Thu, 30 Jul 2020 12:58:04 +0000

I had to implement a React component which takes text and adds links to the detected URLs:

<AutoLink>
  This text contains link to http://example.com and https://example.com
</AutoLink>

This generates the following HTML:

<p>
  This text contains link to <a href="http://example.com" target="_blank">http://example.com</a> and <a href="https://example.com" target="_blank">https://example.com</a>
</p>

"a,b,c".split(/,/) // => ["a", "b", "c"]

Today I learned, that you can actually include the separator in the results:

"a,b,c".split(/(,)/) // => ["a", ",", "b", ",", "c"]

This uses the regular expression group feature.

Using this feature, I created a mapLinks function. It takes the text and yields the links it detects.

const EXP = /(https?:\/\/(?:www\.|(?!www))[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\.[^\s]{2,}|www\.[a-zA-Z0-9][a-zA-Z0-9-]+[a-zA-Z0-9]\.[^\s]{2,}|https?:\/\/(?:www\.|(?!www))[a-zA-Z0-9]+\.[^\s]{2,}|www\.[a-zA-Z0-9]+\.[^\s]{2,})/gi; 

export function mapLinks(text, fn)) {
  // this splits the text, by links but it still keeps those links in the result
  return text.split(EXP).map((chunk, i) => {
    if (chunk.match(EXP)) {
      return fn(chunk, i);
    }

    return chunk;
  });

Then I just used this function for the component itself:

export default React.memo(({ children }) => (
  <p>
    {mapLinks(children, (url, i) => (
      <a href={url} target="_blank" key={i}>
        {url}
      </a>
    ))}
  </p>
)}

My Advice to Junior Developers

Radoslav Stankov — Wed, 29 Jul 2020 12:43:28 +0000

I talk to junior engineers a lot and find myself giving the same advice. So I decided to write a post about it.

There are many online resources about coding or finding a job in the tech sector. This post is not one of those. It is focused on soft skills, which I think a junior developer should have.

So let's get started. 🚀

Your biggest goal is to learn and grow. Most of the habits you pick up in the early days of your career will stick.

Be reliable

ALWAYS follow up on your task commitments.

Don't leave TODO comments in your code, fully complete your work. Leave your code better than you found it.

When you find out that you can't finish a task on time, don't hide it. The moment you think you can't deliver, ask for help.

You have to show that you are reliable. It is the most important thing to do.

Your teammates will quickly learn if they can count on you. The more people count on you, the more critical projects you are given.

Take ownership

Try to be involved in time estimations -- often, you won't be consulted with them (this is a mistake on your team's part).

Don't rush to estimate. Take your time to think about the problem. Consult with team members.

One mistake that everyone does is to provide a time estimation that's as low as possible and then don't deliver. Be honest and conservative.

...and no, doing an all-nighter to finish a task on time is not a proper time planning.

Estimates are tricky, don't hide when you're behind, but embrace it and raise the issue, look for help.

Handling "No"

You will be full of ideas, this is great. However, you will often be told "No".

"No" is essential in product development.

This can be quite painful. Don't get discouraged. Understand the reasoning behind the "No".

Sometimes the idea is just not right or was already tried. Other times, "No" is "we don't have time right now" because of other priorities.

Show, don't tell. If you have an idea, implement it and make a demo. The ability to present your ideas is a valuable skill.

Programmers tend to disagree a lot in abstract and agree when they see the working code.

When I was trying to convince my team at Product Hunt to switch from a standard RESTful API to GraphQL API, I didn't just say "Let's move to GraphQL".

Instead, I implemented a very complex page with GraphQL in a separate branch. I gave a presentation showing all problems GraphQL will solve for us and presented a migration plan. I didn't hide any of the risks associated with GraphQL.

Again, don't get discouraged even if your code prototype is rejected. Understand why.

Be curious

Be curious and ask questions. Don't be content with not understanding things. This is a nasty habit.

Try to review other people's pull request changes. If you don't understand something, ask, often you aren't the only one who doesn't understand. If you are too shy to ask in public, ask directly via private chat message.

I love working with juniors, who ask questions. They are good at spotting too clever code tricks and unnecessary code complexity.

One of the best ways to learn is to work with other people. Ask people if they want to pair program with you.

Boring tasks

In your early days, you will work on many "boring" tasks like bug fixes or minor UI changes. It would help if you tried to find joy even in boring tasks.

Fixing small bugs will show you how your systems are built and how to avoid writing them in the first place.

Once, I was tasked with keeping our application clean of runtime exceptions. This was a very useful experience. It showed me how the system was breaking. I built a lot of internal tooling to handle errors and started designing my code to be more robust.

For small repetitive tasks, you can think about how to automate them or use them as training for your editor skills. I learned my VIM shortcuts by doing a lot of CSS fixes.

Final words

A great book that I'd encourage you to read is The Pragmatic Programmer. I think every programmer should read it.

On the technical side - master your editor and the programming language you are working with.

Last but not least - take care of yourself. Work hard, but don't overwork. Get enough sleep every night.

TL;DR

A lot of the habits and skills you build at this stage in your carer will stick.

ALWAYS follow up on your time commitments
Try to have a positive attitude
Be pro-active, curios and learning (even from tedious tasks)
Don't get discouraged when people say "No" to your ideas
Read the The Pragmatic Programmer
Take care of yourself

If you have any questions or comments, you can ping me on Twitter.

Using "data-test" in Tests

Radoslav Stankov — Sat, 29 Jun 2019 08:19:29 +0000

When testing HTML components, I often see people using class names as selectors. For example:

element.find('.description button.expand-button').simulate('click');

While this seems convenient at first, there are some drawbacks. HTML structure and css classes tend to change due to design changes. Which will cause you re-write tests quite often. Also, if you are using css-modules you can't rely on class names.

Because of that, for quite some time now, I have started marking elements with data-test attribute.

React example (using enzyme and chai-enzyme):

describe(Description.name, () => {
  it('cut off text based on `cutoffLength`', () => {
    const el = shallow(<Description text="test" cutoffLength={1} />);

    expect(el).to.have.text('t...');
    expect(el).not.to.have.text('test');
  });

  it('hides expand button when text is short', () => {
    const el = shallow(<Description text="test" cutoffLength={10} />);
    expect(el).not.to.have.descendants('[data-text="expand-button"]');
  });

  it('shows expand button when text is long', () => {
    const el = shallow(<Description text="test" cutoffLength={1} />);
    expect(el).to.have.descendants('[data-test="expand-button"]');
  });

  it('clicking expand button reveals the whole text', () => {
    const el = shallow(<Description text="test" cutoffLength={1} />);

    el.find('[data-test="expand-button"]').simulate('click');

    expect(el).not.to.have.descendants('[data-test="expand-button"]');
    expect(el).to.have.text('test');
  });
});

The component code:

import React from 'react';
import styles from "./style.css";

export default Description extends React.Component {
  state = { expanded: false };

  render() {
    const { text, cutoffLength } = this.props;

    if (this.state.expanded || text.length < cutoffLength) {
      return (
        <div className={styles.description}>
          {this.props.text}
        </div>
      );
    }

    return (
      <div className={styles.description}>
        {`${ text.substr(0, cutoffLength) }...`}
        <button 
          data-test="expand-button" 
          className={styles.expand} 
          onClick={this.expand}>show more</button>
      </div>
    );
  }

  expand = () => {
    this.setState({ expanded: true });
  };
}

I'm also using data-test attributes for testing with Capybara in Ruby land.

describe 'Product page' do
  it 'has product description rev' do
    product = create :post, :with_long_description

    visit product_path(product)

    expect(page).not_to have_text product.description

    # This can be extracted into `find_test_attr` or `click_test_attr`
    find(:css, '[data-test="expand"]').click

    expect(page).to have_text product.description

    # This can be extracted into `have_test_arr`
    expect(page).not_to have_css('[data-test="expand"]')
  end
end