pengx17
commented
2 years ago This is very interesting and is what I want to achieve at the beginning.
Some already know limitations:
Slow performance (even in production build), don't know why. Query is not supported. (We can implement it in the future) Path organization (we need to rewrite the transform module)
I guess you ran TuanManhCao/digital-garden against a Logseq graph? I am surprised it would work for Logseq as well.
I went through briefly of how https://github.com/TuanManhCao/digital-garden parsing the files. It uses Next.js static generation to build the graph & pages and I think it will be very slow on first rendering (since it will build the graph in the server on demand).
I think it is still a long way to go to make it for Logseq. The graph building is a lesser issue for Logseq, but since Logseq is an outliner and has more custom syntax, it makes parsing and rendering Logseq pages a harder problem.
Parsing is not a big issue since we can use https://github.com/logseq/mldoc to build the AST for each file. However when comes to rendering, it becomes much more tricky, since it has block-refs, embeds, macros, properties, TODO markers etc.
Though I think it is possible to do it in JS, I feel like migrating them from the huge Logseq ClojureScript codebase will be a pain. Based on the facts, I have no short term plan to do it as it seems requiring at least a couple of months of full-time working, but I am willing to contribute to it if you want to it :D
Xuanwo
Hi, @pengx17
I came across into project TuanManhCao/digital-garden recently. It's an Obisidian Publish alternative and seems we can adapt it a bit to make it works on logseq. Do you have an interest to make it happen?
Some already know limitations:
Queryis not supported. (We can implement it in the future)Similiar Projects