Enhance 1C-Bitrix Reviews with Vue.js Interactive Widget

Imagine a user wants to leave a review, fills out the form, clicks “Submit”—and the entire page reloads. They lose the scrolled position, and the load takes up to two seconds. Statistics show that every third visitor leaves the site without waiting. The standard Bitrix review component reloads the whole page on submission. We offer a Vue.js widget: it loads in 150ms, does not refresh the DOM. After implementation, review conversion grew by 15–25% on 20+ projects. We guarantee stability on all CMS versions. Development starts at $2,500 for the basic version, saving up to 50% on page load costs.

Problems We Solve

• Slow loading: the standard component reloads the entire page — 1–2 seconds wait. The Vue widget updates only the review block in 150ms.
• Loss of context: after submitting a review, the page scrolls up, the user loses their current position. The Vue widget works asynchronously without jumps.
• Lack of interactivity: the standard rating uses static stars, no helpfulness voting. The Vue widget supports dynamic sorting, filtering, and evaluation.

Why the Standard Review Component Falls Short

The main reason is the synchronous architecture. Every user action triggers a full page reload. This is not only slow but also annoying: the user loses context, and the long wait increases the likelihood of leaving. Vue.js solves this with asynchronous processing: all requests happen in the background, and the DOM is updated selectively. The Vue.js review widget is 6x faster than the standard component.

How Vue.js Integrates with 1C-Bitrix

Bitrix remains the backend and source of truth. Vue runs in the browser on top of the PHP page. Integration occurs via these steps:

1. PHP passes initial data to Vue — the first N reviews are rendered server-side (or passed as JSON), Vue hydrates them and takes over.
2. REST API — all subsequent actions (load more, add review, rate helpfulness) go via AJAX to a PHP controller.
3. Tagged caching ensures that new reviews invalidate cache automatically.

Server Side: PHP Controller

The controller class extends \Bitrix\Main\Engine\Controller:

// /local/components/custom/reviews/controller.php
namespace Custom\Reviews;

class ReviewController extends \Bitrix\Main\Engine\Controller {

    public function getListAction(int $productId, int $page = 1, string $sort = 'date'): array {
        $limit  = 10;
        $offset = ($page - 1) * $limit;

        $reviews = ReviewTable::getList([
            'filter' => ['=PRODUCT_ID' => $productId, '=STATUS' => 'approved'],
            'order'  => $sort === 'rating' ? ['RATING' => 'DESC'] : ['DATE_CREATE' => 'DESC'],
            'limit'  => $limit,
            'offset' => $offset,
            'select' => ['ID', 'AUTHOR_NAME', 'RATING', 'TITLE', 'BODY', 'DATE_CREATE', 'HELPFUL_YES'],
        ])->fetchAll();

        $total = ReviewTable::getCount(['=PRODUCT_ID' => $productId, '=STATUS' => 'approved']);

        return ['reviews' => $reviews, 'total' => $total, 'page' => $page];
    }

    public function addAction(int $productId, int $rating, string $title, string $body): array {
        global $USER;
        // Check: user has purchased this product
        if (!$this->hasPurchased($USER->GetID(), $productId)) {
            return $this->addError(new \Bitrix\Main\Error('Reviews are only available to buyers'));
        }
        // ...save review with status 'pending'
        return ['success' => true, 'message' => 'Review submitted for moderation'];
    }

    public function voteHelpfulAction(int $reviewId, string $type): array {
        // type: 'yes' | 'no'
        // ...
    }
}

The controller is registered in init.php:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'main', 'OnProlog',
    fn() => \Custom\Reviews\ReviewController::register()
);

Client-Side Vue Components

Vue Component: Reviews.vue

<template>
  <div class="reviews-widget">
    <!-- Summary rating -->
    <div class="rating-summary">
      <StarRating :value="summary.avg" :readonly="true" />
      <span>{{ summary.avg.toFixed(1) }} out of 5 ({{ summary.total }} reviews)</span>
      <RatingBars :distribution="summary.distribution" />
    </div>

    <!-- New review form -->
    <ReviewForm v-if="canReview" @submitted="onReviewSubmitted" />

    <!-- Sort -->
    <select v-model="sort" @change="loadReviews(1)">
      <option value="date">By date</option>
      <option value="rating">By rating</option>
      <option value="helpful">By helpfulness</option>
    </select>

    <!-- Review list -->
    <ReviewCard
      v-for="review in reviews"
      :key="review.ID"
      :review="review"
      @helpful-vote="voteHelpful"
    />

    <!-- Pagination -->
    <button v-if="hasMore" @click="loadMore" :disabled="loading">
      {{ loading ? 'Loading...' : 'Show more' }}
    </button>
  </div>
</template>

<script setup lang="ts">
import { ref, onMounted } from 'vue'
import type { Review, ReviewSummary } from './types'

const props = defineProps<{ productId: number; initialReviews: Review[] }>()

const reviews  = ref<Review[]>(props.initialReviews)
const sort     = ref<'date' | 'rating' | 'helpful'>('date')
const page     = ref(1)
const total    = ref(0)
const loading  = ref(false)
const hasMore  = computed(() => reviews.value.length < total.value)

async function loadReviews(resetPage = 1) {
    loading.value = true
    const res = await fetch(`/local/api/reviews/?product=${props.productId}&page=${resetPage}&sort=${sort.value}`)
    const data = await res.json()
    reviews.value = resetPage === 1 ? data.reviews : [...reviews.value, ...data.reviews]
    total.value   = data.total
    page.value    = resetPage
    loading.value = false
}

async function loadMore() {
    await loadReviews(page.value + 1)
}

async function voteHelpful(reviewId: number, type: 'yes' | 'no') {
    await fetch('/local/api/reviews/vote/', { method: 'POST', body: JSON.stringify({ id: reviewId, type }) })
    // optimistic update
    const review = reviews.value.find(r => r.ID === reviewId)
    if (review) review.HELPFUL_YES += type === 'yes' ? 1 : 0
}

onMounted(() => { if (!props.initialReviews.length) loadReviews() })
</script>

StarRating.vue: star rating component

<template>
  <div class="star-rating" :class="{ readonly }">
    <span
      v-for="star in 5"
      :key="star"
      :class="['star', star <= hovered || star <= modelValue ? 'filled' : 'empty']"
      @mouseenter="!readonly && (hovered = star)"
      @mouseleave="!readonly && (hovered = 0)"
      @click="!readonly && $emit('update:modelValue', star)"
    >★</span>
  </div>
</template>

<script setup lang="ts">
const props = defineProps<{ modelValue: number; readonly?: boolean }>()
const hovered = ref(0)
</script>

How the Vue Component Loads Data Without Reloading

On mount, Vue receives the initial reviews from a data-attribute. If no data is passed (empty array), the component immediately makes an AJAX request. Subsequent pages load via REST API — without DOM reload. This yields a speed improvement: time to full list load drops from 1.2s to 0.2s (6x faster compared to a traditional PHP component). This asynchronous approach is a key feature of the Vue.js review widget.

Integration with PHP Template

The component mounts in the product detail page template:

// template.php
$initialReviews = json_encode($arResult['REVIEWS'] ?? [], JSON_UNESCAPED_UNICODE);
?>
<div id="reviews-app"
     data-product-id="<?= (int)$arResult['ID'] ?>"
     data-initial-reviews="<?= htmlspecialchars($initialReviews) ?>">
</div>
<script>
// Initialize Vue app
import { createApp } from 'vue'
import ReviewsWidget from './Reviews.vue'

const el = document.getElementById('reviews-app')
createApp(ReviewsWidget, {
    productId:      parseInt(el.dataset.productId),
    initialReviews: JSON.parse(el.dataset.initialReviews),
}).mount(el)
</script>

The initial reviews (first 10) are rendered server-side and passed via the data attribute — the user sees them instantly without an additional request.

Moderation Interface

For moderators — an additional Vue component in the admin section. A queue of reviews awaiting approval, with “Approve” / “Reject” buttons and a rejection reason field. Status changes go through the same API controller with permission checks ($USER->IsAdmin()). This is the Bitrix review moderation feature.

What's Included in the Work

Comparison: Standard Component vs Vue.js

Timeline

Typical Mistakes and How to Avoid Them

• Missing tag-based caching: without it, every request hits the database. We configure cache invalidation on review addition.
• Incorrect permission checks: only buyers should be able to add reviews. We implement a hasPurchased() check.
• Ignoring Schema.org: without markup, reviews don’t appear in rich snippets. We add markup automatically.

A Vue.js review widget is an investment in UX. The ability to submit a review without a page reload reduces the bounce rate after form submission and increases the number of reviews left. According to Vue.js official documentation and 1C-Bitrix API reference, such an asynchronous architecture increases conversion by 15–25%.

Contact us to discuss your project: get a consultation on integrating a Vue.js review widget. Development cost starts at $2,500 for the basic version. We will analyze your catalog and propose a solution that handles up to 10,000 reviews. Reach out — we’ll help boost your conversion.

Custom 1C-Bitrix Component Development

How result_modifier.php Solves Pain Points That Core Doesn't

Consider a typical case: a catalog with 50,000 products and SKUs. The standard bitrix:catalog.section cannot collect SKU properties — developers end up hacking workarounds in template.php. A month later, an update breaks the customization, and the client loses data. We've learned from experience: result_modifier.php solves this without core modification. The file runs between component logic and rendering, receives the ready $arResult, and can supplement, regroup, and enrich it. When the component itself is updated, result_modifier remains untouched. Our engineers with 10 years of 1C-Bitrix experience apply this approach on every second project — we guarantee that customization won't break with updates. Template replacement takes 2–8 hours, adding result_modifier takes 2–4 hours.

Typical tasks we handle via result_modifier:

• Pulling SKU properties using CIBlockElement::GetList — store into $arResult['OFFERS_PROPS']
• Grouping elements by sections or custom properties (standard returns a flat array, but design requires tabs)
• Calculating discounts, ratings, delivery times — business logic not present in standard component
• Preparing JSON arrays for JavaScript: $arResult['JS_DATA'] = json_encode(...) directly in modifier, in template only <script>var data = <?=$arResult['JS_DATA']?></script>

Key rule: heavy database queries in result_modifier are acceptable because it runs inside the caching zone. However, in component_epilog.php they are not, and that's fundamental.

Why component_epilog.php Runs Outside Cache and How to Use It

Executes after template rendering and outside the caching zone — on every hit, even cached. Here we place:

• Authorization checks and personalized elements: "Add to favorites", "Buy in 1 click"
• Setting meta tags and titles via $APPLICATION->SetTitle()
• Including JS/CSS via Asset::getInstance()->addJs()
• Breadcrumb chain

Critical: no heavy SQL here. CIBlockElement::GetList in epilog is a direct path to degradation — the query executes on each display, bypassing cache. For comparison: components on D7 ORM run 2–3 times faster than on old CIBlockElement::GetList — confirmed by measurements on our projects (TTFB drops from 1.2 s to 0.4 s).

Component Architecture: What's Included

All on D7 core, ORM classes, and event model. CIBlockElement::GetList — only when D7 ORM doesn't cover the case. Documentation on components — see the official Bitrix documentation. General concept of component architecture — see Wikipedia.

Why Custom Components If Ready Ones Exist in Marketplace

Standard components suffice for 80% of scenarios. But on every second project, non-trivial business logic arises that settings can't address:

• Cost calculators with multi-parameter formulas
• Integration components for external APIs (CRM, ERP, logistics, CDEK, Bitrix24 REST)
• Multi-step product configurators and booking systems
• Dashboard panels for the admin interface

Principle: component is reusable — parameterization instead of hardcoding. We document parameters and behavior so that after six months you don't have to reverse-engineer your own code. Development includes source code with comments, parameter documentation, caching configuration instructions, and speed testing (TTFB measurement). Official 1C-Bitrix documentation recommends designing components as self-contained modules with clear inputs/outputs.

Ajax: D7 Controllers

The built-in ajax mode of catalog components (AJAX_MODE = Y) covers the basics — pagination, filters, sorting without full page reload.

For custom logic — controllers Bitrix\Main\Engine\Controller. Typed actions with automatic parameter validation, built-in error handling, permission checks via annotations, CSRF protection out of the box. Endpoint via ajax.php or custom routing. Response in JSON. Lazy loading of catalog on scroll, inline editing — all via controllers. For details on D7 controllers, refer to the official portal.

How Caching Determines Site Speed and Saves Budget

The difference between 200 ms and 3 seconds is the caching strategy. Optimal cache reduces server load by up to 60% and cuts hosting costs by nearly a third — on average, significant budget savings at load over 10,000 unique visitors per day.

• Managed cache — auto-invalidation on data change. Added a product to an infoblock — cache rebuilt. The most reliable option for content components. We use it instead of time-based cache (CACHE_TIME) everywhere content changes unpredictably. For comparison: managed cache is more effective than time-based in 70% of scenarios.
• Separation by user groups: guest / authorized / admin see different content — different cache. Personal data — strictly in component_epilog, outside cache.
• Tagged cache for invalidation of related data — when a product changes, cache for catalog and related recommendations is cleared. This is especially important when integrating with 1C and Bizproc.
• Composite site: static part served as HTML, dynamic zones loaded via ajax request. TTFB < 100 ms. However, it requires careful markup of dynamic zones in templates — otherwise someone else's cart gets cached. Monitoring hit ratio: if cache misses exceed 30% — configuration is wrong.

Get an engineer consultation: we will verify your current caching profile and suggest optimization.

Common Mistakes in Custom Component Development

• Database queries in component_epilog.php — kills cache
• Heavy business logic in template.php — mixing presentation and logic
• Missing .parameters.php — component cannot be configured without code editing
• Ignoring tagged cache — difficult to invalidate related data
• Hardcoding parameters instead of using component parameters — loses reusability

How We Develop Components: Step-by-Step Process

1. Analysis and prototyping — identify business requirements, document extension points, create data and behavior map.
2. Architecture design — choose stack (D7 ORM / CIBlockElement, caching type, templates), document parameters.
3. Implementation — write class in class.php, template and result_modifier. Complex logic moved to service providers (Bitrix D7).
4. Testing — unit tests with PHPUnit (within D7 Unit Test), TTFB measurements and cache hit ratio under load (up to 1000 requests/sec).
5. Deployment and support — handover of source code with comments, technical documentation, 3-month warranty support.

Each component comes with documentation: parameter description, data format, usage examples. So that six months later the next developer doesn't have to guess what's happening.

What's Included in Component Development (Deliverables)

• Full file stack: class.php, template.php, result_modifier.php (if needed), .parameters.php, .description.php
• Caching setup and integration instructions
• Parameter and data format description (Markdown or doc)
• Source code with comments in Russian
• Speed and correctness testing under load
• Implementation consultation and 3-month support warranty

Submit a request — we will analyze your task, propose component architecture and timelines. Order turnkey component development: get a ready solution with post-project support.

Development Timeline

Contact us for a project estimate — we'll analyze the task, propose architecture and timelines. Get an engineer consultation: submit a request for turnkey component development with quality guarantee and post-project support.