Skip to content

Polotno Integration

The Polotno editor is the core design surface of this app. It's a React 18 + MobX-State-Tree + Polotno 2.13.10 subproject living under polotno-editor/, separately built into polotno-bundle.js and consumed by Vue pages as a black-box bundle.

Subproject layout

polotno-editor/
├── package.json                    # 15 runtime deps
├── package-lock.json
├── index.html                      # standalone dev page (parcel)
├── index.js                        # entry — exports createEditor(...)
├── App.js                          # main React app component
├── app.css
├── CustomPageControls.js
├── CustomWorkspace.js
├── alltemplatesPanel.js
├── brandkitPanel.js
├── carousaltemplatesPanel.js
├── templatesPanel.js
├── customUploads.js
├── icons.js
├── helper.js
├── mediaGrid.js
├── ModalPortal.js
├── Pexels.js
├── PexelVideos.js
└── QrSection.js

Notable: the subproject has its own node_modules and its own dev workflow (parcel index.html → http://localhost:1234).

Workflow (per README.md at the repo root)

cd polotno-editor
yarn install
yarn dev            # parcel; standalone editor at localhost:1234

# When ready:
yarn build          # parcel build → writes ../polotno-bundle.js at the repo root

The Vue app then imports ../polotno-bundle.js (via static <script> injection or dynamic import) and calls createEditor({ container: document.getElementById("polotno") }).

Critical workflow caveat

The subproject's package.json lists Polotno's React + MobX deps. These deps are not bundled by yarn build — they are expected to be present in the parent app's node_modules too. The README warns:

Important note: it will not bundle any external dependencies that you will have listed in ./polotno-editor/package.json. You may need to install them again in your root folder, so they are presented in ./polotno.json too.

So the parent package.json includes React 18, react-dom 18, mobx, mobx-react-lite, mobx-state-tree, polotno, react-filepond, etc. — duplicating the subproject's deps.

If a version drifts between parent and subproject, runtime breakage can ensue.

Pages that mount the editor

  • pages/templateEditor.vue, pages/templateEditor1.vue, pages/carousaltemplateEditor.vue
  • pages/postEditor.vue, pages/postcreator.vue, pages/postdesigner.vue
  • pages/mediaEditor.vue, pages/MastermediaEditor.vue, pages/PreproductionPostEditor.vue
  • Maybe more — grep -l "polotno-bundle\|createEditor" pages/ would enumerate

Each editor page: 1. Mounts a <div id="polotno"></div> 2. Loads polotno-bundle.js (probably via <script> in the page's head or via mounted() import) 3. Calls createEditor({...}) once mounted 4. Reads from / writes to window.store (the MobX store the editor exposes)

The Vue ↔ React boundary is the only API contract: the editor exposes createEditor, window.store, and maybe event hooks. Don't deep-couple Vue components to internal MobX state — that breaks on every Polotno upgrade.

Polotno license

Embedded in the editor's source somewhere (likely App.js or index.js). Search: grep -nE "polotno.com|setLicenseKey|licenseKey" polotno-editor/*.js.

Verify: hardcoded vs env-driven. If hardcoded, anyone with repo read access can extract and abuse the license.

Comparison to someli-platform/polotno-editor/

The two editors are forked siblings. Concrete differences (from diff -rq between the two polotno-editor/ directories):

  • Only in someli-platform/polotno-editor/: aiContent/, aiImage.js, common/, customTextSection/, favouritesPannel.js, helper/, ImageLibraryPanel.js
  • Only in Someli-Designer/polotno-editor/: alltemplatesPanel.js, CustomPageControls.js, CustomWorkspace.js, helper.js
  • Renamed: brandkitpanel.js (customer) vs brandkitPanel.js (designer)
  • Diverged: App.js, app.css, carousaltemplatesPanel.js, customUploads.js, icons.js, index.html

The customer editor is much richer (AI content + AI image panels, image library panel, favourites panel). The designer editor is leaner but has its own template-admin features (alltemplatesPanel, CustomWorkspace).

This split is intentional — staff don't need the customer-facing AI panels; they need template-curation tools.

Implication: don't try to share code between the two polotno-editor/ directories at this point. They are two products. If a shared core is desired, it would need to be a third repo (e.g., someli-polotno-core) that both depend on.

Storage / persistence

Per the customer editor's pattern (verify for designer): designs in progress are persisted to localStorage, keyed by pathname+hash, debounced 2 seconds. The user can refresh the editor page without losing work.

The persisted designs are per-browser, not server-side. If a user moves between machines, they lose their in-progress design.

Polotno bundle artifact

polotno-bundle.js at the repo root is the committed build output. It's ~50 KB (much smaller than someli-platform's 221 KB customer editor). The bundle is checked in:

polotno-bundle.js
polotno-bundle.js.map

This means a developer doesn't need to rebuild the editor to run the Vue app — they can pull the latest bundle from git. But the bundle can also drift if someone edits the editor source without committing the rebuilt bundle. Recommendation: add a pre-commit hook or CI check that rebuilds the bundle if polotno-editor/ source changed.

Recommendations

ID Recommendation Effort
P-1 Move Polotno license to env (process.env.POLOTNO_LICENSE) if hardcoded Small
P-2 Add CI gate: if polotno-editor/**/*.js changed in PR but polotno-bundle.js didn't, fail the build Small
P-3 Align Polotno/React/Mobx versions between subproject and parent package.json Small
P-4 Document the Vue ↔ React boundary (what the Vue app expects from the bundle: createEditor, window.store, events) Trivial
P-5 Consider server-side design persistence for cross-device support Medium
P-6 Audit the bundle size on production builds; flag growth Trivial