Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any plan for docs of abstract components? #720

Closed
myst729 opened this issue Jan 19, 2017 · 8 comments

Comments

@myst729
Copy link
Contributor

commented Jan 19, 2017

There are several built-in abstract components, such as transition, keep-alive. However, the official guide doesn't tell the developers that they could also create their own.

Here's a possible use case. If the user's network is very good, I may want to guess his/her behavior based on some rules, and prefetch some async data or routes. So I create a prefetch abstract component. When the user really does what I have guessed, the UI could response immediately.

After read source code of the built-in abstract components, I found that there are pitfalls I didn't realize. For example, an abstract component may contain another abstract component. Then I start to worry whether I could use it the right way.

Is abstract designed to be internal only, or is there any plan for the docs?

@chrisvfritz

This comment has been minimized.

Copy link
Member

commented Jan 19, 2017

My understanding is that it's internal-only, but I'll ping @yyx990803 to double check.

@myst729 myst729 changed the title [Question] Any plan for docs of abstract components? Any plan for docs of abstract components? Jan 19, 2017

@yyx990803

This comment has been minimized.

Copy link
Member

commented Jan 19, 2017

For now it is internal only. I'm interested to see more details about your use case though, that may help validate the idea and see whether we can make it public.

@myst729

This comment has been minimized.

Copy link
Contributor Author

commented Jan 20, 2017

I'm involved in a big data product.

  1. In the product we have some super large data grids - the list view. At this step, we couldn't guess much.
  2. When the customer clicks an item in the list, he gets to the item's highlights view - selected potion of data (1/5 roughly) that customers most concern about.
  3. According to some user behavior studies, more than 60% of customers will go on click the expando, which reveals the rest 4/5.

To be honest, there could be a way to improve the design, so does technical design. Despite that, this looks like a typical use case for prefetching data (step 2 -> 3).

Here's the sample prefetch component:

<script>
  export default {
    name: 'prefetch',
    abstract: true,
    render: () => '',
    props: ['api'],
    watch: {
      api (val) {
        if (val) {
          // Use fetch here for quick prototyping,
          // Should use cancellable method in production.
          fetch(val)
            .then(response => response.json())
            .then(data => {
              this.$store.dispatch('prefetchData', data)
            })
        }
      }
    }
  }
</script>

In root component, dataPath is a computed property based on current route:

<prefetch :api="dataPath"></prefetch>

For now, the approach is experimental. And it's definitely not the only way to achieve such functionality, a util method could also do the job. So I couldn't say I need it desperately. I'm just trying to implement the idea that everything could be a component. If abstract components are meant to be internal only, I'm still ok with it.

@vbarbarosh

This comment has been minimized.

Copy link

commented Jan 21, 2017

Hi, I asked a question on stackoverflow related to this issue. My use case is simple. I just want to have a component which will add a property to its child component but will not change html at all.

From this:

<div id="app" class="container">
    <foo>
        <p>hello</p>
    </foo>
</div>

To this:

<div id="app" class="container">
     <p>hello</p>
</div>
@myst729

This comment has been minimized.

Copy link
Contributor Author

commented Oct 30, 2017

There's not many responses since it was opened. And it's not the only way how I could meet my development task. Close the issue.

@giodif

This comment has been minimized.

Copy link

commented Jun 23, 2018

Hi. I have run into a case where this might be pretty useful. I'm new to Vue, so there may already be a good solution for what I'm presenting. I looked through the docs and through issues and didn't see anything that might help.

I'm working on a project that uses canvas pretty extensively to draw graphs. I've worked with React where creating abstract components isn't a problem. I guess that I assumed the case would be the same in Vue (not a criticism, Vue is the cat's pajamas).

Let me explain the use case:

I'd like to make a series of components that encapsulate drawing operations to a canvas. Think: <weighted-edge>, <unidirectional-edge>, <bidirectional-edge>, <graph-node>, etc. These nodes need simply to contain the logic for drawing to the canvas, hence no rendering new DOM elements. I originally sketched out a hierarchy like so, (before I painted myself into a corner):

<canvas-stage>
    <weighted-edge v-for="edge in edges" ctx="ctx">
    <graph-node v-for="node in nodes" ctx="ctx">
    ...etc...
</canvas-stage>

The idea is that a parent component handles the canvas and passes the context down into all the child abstract components, which handle drawing. My thinking is that this might provide a simple way of managing draw layers to the canvas and for maintaining drawing operation code. If you've ever worked on a project with lots of drawing, it usually ends up a pain to maintain.

My point is that some 'view' elements aren't always DOM elements. The canvas is a pretty complex element and it'd be most excellent to use Vue components (and vuex) to manage the state of a canvas image. Having access to abstract components would make it somewhat easier to incorporate more robust drawing libraries as well.

Anywho, just my two cents.

@chrisvfritz

This comment has been minimized.

Copy link
Member

commented Jul 15, 2018

@giodif This kind of pattern is actually very doable with Vue currently - I use it quite often. 🙂 You can see a simple example here using MapboxGL, though in a real-world context I like to use provide/inject instead of $parent for sharing context with descendent components.

@giodif

This comment has been minimized.

Copy link

commented Jul 16, 2018

@chrisvfritz Thanks for the example, makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.