The deploy loop
This was not the best developer experience. I had just finished wiring up a new field to a custom DX component, made a two-line change, and hit save. What followed was the full ceremony:
- npm run publish,
- upload to Pega,
- refresh the app,
- hard-reload the browser — only to realize the prop name had a typo. Start over.
There had to be a better way. There is. And it took me embarrassingly long to find it, so sharing with others so they find it sooner than later.
What the local dev flow gives you
When you run the Constellation component library in local development mode, the Pega application running in your browser swaps out the component bundle it would normally fetch from the server and pulls from your local dev server instead. Think of it as a live sidecar - you change code, the browser reloads, the running case reflects the update instantly.
The old loop (every single change):
Edit code → npm run publish → zip + upload → hard reload → repeat
The local dev loop:
Edit code → browser hot → reloads → done
Getting the dev server running
Process of setting up local server is well described in documentation: https://docs.pega.com/bundle/constellation-dx-components/page/constellation-dx-components/custom-components/debug-component-library.html
Best practices
Here are couple of observations to
• Keep the component count low — the dev server needs to build all registered components on startup. Comment out anything you are not actively working on in your entry point. Fewer components = faster cold start and faster incremental rebuilds.
• WSL / container users — if your dev server runs inside WSL or a container, localhost in the Windows browser will not reach it you need to expose ports
• Switching back to server mode — revert the Constellation DXCB Dev URL on your operation back to blank value. Everything else stays the same. Otherwise when you stop dev server Pega will not be able to serve components
• Publish on milestone – publish your component to Pega Infinity server after development milestones, as of now your changes are only local
Debugging process
After successful setup you can enjoy local development experience:
• HMR (Hot Module Replacement) — webpack will push changes to the browser without a full reload for most edits. State is preserved in the running case, so you can iterate on rendering logic without restarting the flow.
• Breakpoints in VS Code — attach the debugger in code
and then debug in browser
• Breakpoints in the browser — because the dev server emits source maps, DevTools Sources panel shows your original component files rather than the bundle. Set breakpoints there directly
Enjoyed this article?
See suggested articles from our Constellation 101 series and view all our Knowledge Shares from our User Experience Expert Circle.